OK, that's cool - and that was all I was asking for. I'm puzzled as to why other posters regard it as though it's like pulling teeth and expect me to jump through hoops for them before I get a reasonable answer. Let's have a look!

So first of all, looking at these in a cursory manner, these are not "logical errors" in terms of software engineering - the term has a very specific meaning which is whereby programming instructions that are syntactically correct nevertheless produce erroneous return data. What you're describing here is a situation where a system operating in the field has produced results that highlight potential issues going right back to the specification (or indeed a set of circumstances that the original specification did not or could not take into account) - the result of which is what us nerds refer to as a "change request".

Now I've got that rather dull bit of nitpicking out of the way, let's dig in.

1. Limiting the autotrim in response to a stall warning sounds good in theory, but you're going to have two major problems right off the bat. The first is quite simple, and that is "what happens if the stall warning is false?". I can foresee a couple of situations off the top of my head where that could be more dangerous than letting the trim run. The second is a bit more esoteric and complex, and indeed can apply to all the things you're talking about, and that is the increase in complexity such a change will add to the system as a whole. Determining the knock-on effect that change would have is a very involved process and the logic paths would have to be scrutinised at a very in-depth level, and of course you run afoul of the old engineering maxim that adding complexity is increasing the number of potential points of failure. That said, it looks like the A320 has a hard nose-up limit on the autotrim in Alternate of 3 degrees, while the A330 does not. I'd be interested to know what they discovered inbetween development of the two airliners that led to that change. I think that a hard limit would probably be a more effective solution than checking against Stall Warning status (which is after all in a completely different subsystem and may or may not be valid).

2. I wouldn't be surprised if most airliner designs of a mid-80's vintage or later have similar logic. Determining whether a stall warning is valid or not has been a tough nut to crack for a long time, and in an overwhelming majority of cases, the limits set probably make good sense - I mean this is the only case where it has been perceived as an issue and in order to make it one the aircraft was taken further out of the flight envelope than any test pilot would dare attempt. On paper it looks sensible, because Stall is a function of AoA, and the limit of the AoA vanes' effectiveness as reported by the supplier is <60kts. I saw talk of using a WoW switch earlier, and I don't think that the designers would assume that if the computed speed is less than 60kts then the aircraft must be on the ground, given how in-depth they went and how many permutations they went through to arrive at the spec they did. In their shoes I'd be thinking "if we know that the data is going to be unreliable past this point, then it's probably best discarded". Unfortunately they didn't bet on the set of circumstances that caused AF447 (specifically "what if an aircraft was held in a stall to the point where that limit is reached?"), and even those who have no particular love for Airbus have to admit it's an edge case to end all edge cases. I have no clue how easy or difficult it would be to latch the current stall warning status when that limit is reached, and I foresee complexity arising from what to do once a recovery has been effected (namely "We've latched stall warning because we can't trust the data, so at what point can we start trusting it again?").

These are definitely trickier as they depend on a given reading of the DFDR data in Interim #3.

3. Are you sure that the V/S trace indicates mode-switching from air data to inertial and back? I was told that the extreme variations towards the end of the trace indicate the static ports being fouled by the airflow induced by the stall, and it is not until the computed airspeed is in the low 100kts area (by which point the stall is well-established) that the readings start to look wrong

4. For starters, I'm not sure how to read the FD trace accurately, but they are inhibited when airspeed data is lost (as you'd expect them to be) - those spikes during the period of actual UAS indication might indicate attempts to re-engage them manually, but I have to defer to more knowledgable folks there. The FDs come back on (as they are designed to) when the airspeed data returned and then switch off again as the aircraft slows to the point where presumably the stalled air is playing merry havoc with the pitot/static and AoA sensors

In these cases, the situation the aircraft found itself in was so extreme that I wouldn't know where to start in terms of getting reliable and accurate data. I wonder what difference having the BUSS might have made?

Hi,

AlphaZuluRomeo
Air data is 100% reliable .. provided that air data is gathered by a reliable captor
So far ... it's proofed that under certain conditions (who are common for a A330 or any modern airliner) those captors are not reliable and can send false or not information at all to the automatic system
So the industry must not renounce "automation" .. provided they correct the weaknesses
Apparently nothing positive was made for correct the problem ... but paper work and modified training
It's agravated by the fact that this problem is know from ages ..
The original problem stay hidden rear the corner

Clandestino
I read in the BEA report N°3 (CVR extracts) that the pilots are telling .. they don't understand and they have no more indications
Or .. the BEA affirm that all was functioning normally (less airspeed indications) and the plane was airworthy
So how you call people facing instrument panel working in a plane working and who are telling they understand nothing ?

It didn't seem idiotic at the time, it wasn't just one person passing that information along and I had (and still have) no reason to believe that they would deliberately misinform me, in fact it's likely someone misinformed them.

In fact the moderators deleted a whole swath of posts from that period and at no point was I contacted directly by the moderating team saying I had erred or otherwise - you make it sound like I was singled out for admonishment when it was not the case.

Aside from the fact that I participate in these forums as a way of taking my brain off the software development track for short periods of time, I have no access to the IP logs of this forum and therefore no way (or at least no *legal* way) of telling - other than building relationships with knowledgeable and trustworthy posters - people are who they say they are. The heads-up came from more than one person, at least one of them had proven trustworthy in the past, and it happened during a period of a lot of people who had previously been curiously silent sticking their oar in, and at least one user going under two different handles (i.e. sockpuppeting). As I said before, none of the moderating team has interacted directly with me either privately or publicly, so I don't know what you're getting at.

If the information was incorrect then, as I said, you have my apology. Other than that I don't know what more I can say or do at this point.

@Old Carthusian:

Hi,

I don't know why you're addressing a reply to me about your flying background - I didn't ask any question about it :)

My earlier replies to you were just trying to help correct the mis-description of what a nose-up AI indication means (or rather doesn't necessarily mean). That interpretation is especially relevant in the case of AF447 when stalled, of course. I thought I would try explaining it slightly differently, to see if that helped, since you were saying the same thing to multiple other members who were also trying to explain the fallacy of your statement as it was written (which you later explained was not what you really meant).

Someone else suggested the discussion about general AI interpretation was off-topic in this thread, and I agreed to stop. That's all :)

While I don't agree with all your comments below, since you've kindly explained some of your thoughts, here are some of my own...

I agree - since HF seems to be a significant contributor to this accident, and humans are involved as flight crew on other airlines, :) personally I have not concluded that only Air France CRM training / assumptions of hand-flying training requirements / etc. [add other human factors as needed] are likely to have been lacking at that time.

In fact I remember another pilot here (not AF as far as I know) who said a while back, that high-altitude manual handling training and high-altitude UAS training had been introduced on his airline after AF447. That suggests such training was also lacking on that airline too, prior to this accident - so AF was not alone, it seems.

Based on my reading, I politely disagree about the "not really". The paper by Dr Lisanne Bainbridge called "Ironies of Automation" seems extremely relevant here (I first found that paper a while ago, via a link in another accident report - NTSB, I think - this is not the first time that AP handed over to pilot, who seemed unable to grasp the situation from a "cold start"). This isn't a criticism of pilots - it's a limitation of humans IMHO.

Also the concept of "startle factor" (when automation unexpectedly hands-over to the pilot) was shown in an AF training slide in an earlier segment of this thread, so this issue is known. The man-machine interface (and humans not being well-suited to a monitoring-only situation, which is more & more the case with modern flying) makes me very interested in the effects of increased automation, and its part in accidents like this.

Perhaps, perhaps not. I don't believe anyone can say that yokes "would not" have helped (nor that they "would have" helped) - we simply don't know, since we can't re-run this scenario with this crew (unless you have a time machine to re-run that flight in an A332 fitted with (preferably coupled/back-driven) yokes :) ). I've seen enough arguments from members here (some quite assertive!) with merit on both sides, to see that there are benefits (and deficiencies) to both systems.

LOC accidents with yoke-equipped aircraft as previously mentioned by other members, show that they are not a panacea. However I don't see how anyone could rule-out in this case, the possibility of the PNF being more assertive (e.g. perhaps taking control earlier) if he was more aware (by having the yoke pressed to his body) of the PF's extreme nose-up inputs. We can't ask him, so we'll never know whether that knowledge might have changed his behaviour :(

I will just point out that the CVR conversation at 2h 13m 40s seems particularly important regarding the [lack of] awareness of the other crew to the PF's inputs - especially since (according to the released CVR transcript), the PF was not verbally communicating his decisions & inputs most of the time. Would a yoke have improved this PNF + Capn awareness enough (and quickly enough) to change the outcome? I don't know, and perhaps only if the PNF or Capn caused a change in PF inputs (or one of them took control) earlier than this point in the sequence - but I doubt that a yoke would have made the PNF & Capn's awareness of the PF's inputs worse. :)

The HF part of the final report will make interesting reading, IMHO.

Regarding my mentioned experience where a A319 did not respond to a nose down SS input: for the brief moment I was in an updraft, the nose did not follow the input - once I flew out of the updraft the nose came down and we continued as if nothing had happened......... Knowing that pitch is load factor demand, and being in a updraft/downdraft/updraft/downdraft situation, and considering that the nose came down as soon as I passed the building cumulus, and considering that the Bus behaved normally the rest of the flight, I chalked it up to being in an Airbus. To me, it was no different than waiting for the MCDU to finish "updating" the page. Airbus pilots will know what I'm talking about.

Sorry Clandestino, but you're being overly dramatic. No report was made because none was necessary.

You are talking about pooling teeth?

I have asked you a clarification on your mentioning of the Airbus design problem with the pitot tubes, and you have not provided that yet. That's not even a new question like you've asked.

You get back exactly what you do, not answering the questions in your queue in a timely fashion......

But actually, I am on this, with my Smoke Detector ON so....

The above maybe confusing, perhaps because of the travail to explain.

Here is an explanation in other words, as a secondary source:
The "logic" behind a program is the "algorithm".
An "error in the logic" of a program is an "algorithm error".
A "software error" or "software bug", is one where the logic followed by the software is correct, but an incorrect outcome or result occurs, in spite of the correct following of the logic, or algorithm.

In high level programming languages a bug is usually caused by incorrect programming of data fields, which pass somehow through the compiler's checks, and which result in handling data which are different than what they're supposed to be. In machine language, which is often used in real-time programming, it may be a slightly wrong programming instruction which is equivalent to the previous mentioned error - for instance the use by mistake of a "load word" instead of "load byte", or "store byte" instead of a "store word", and others...

A "software syntax error" is a typo in a program instruction or program line, which is detected by the compiler - or some smart text editors - and need be fixed, before the compiler would complete successfully its processing.of the program source code. "Syntax errors' are never present in production/running software, as the process of generating the software excludes them.

According to the documenting of the algorithms by Airbus docs, the problems can be identified as being in the algorithms. Therefore, at this stage it seems that the solution of the problem is at algorithm level, not at software level.

Still, one question remains : How long before ?
Let's expect the answer to be somewhere here :

http://i45.servimg.com/u/f45/11/75/17/84/70121610.jpg


The idea Gums is that such question has no reason as the visible yokes have already spoken. Next move on the yoke will tell if correction is applied and applied in the direction you would expect.

Instantaneous non verbal communication - Priceless - IMO - of course.

Diagnostic
Thank you for your courteous response.
I agree that Dr Bainbridge's paper is very valuable in this respect but feel that with good training and professionalism such an effect can be mitigated if not totally avoided. Pilots should not really freeze and lose control if an aircraft does what it is designed to. However, as realistic training as possible is the key hear and this may well be lacking. Hard training, easy execution as the saying goes. From my studies of previous airline company cultural issues I think that automation is the way to go but there are caveats as you observe.
Whilst you are correct about the hypothetical nature of my comments on yokes I feel that the balance of probabilities bears it out. Given the actions of the flight crew that night and that the PNF did take some ineffective action before calling the captain I cannot think that a different input method would have changed things. I also think that the PNF comments 2:10:26 to 2:10:36 where he tells the PF to go back down three times are highly significant and indicate an awareness derived from his instruments. The PNF also warns the PF (2:11) to 'touch the lateral controls as little as possible' once again indicating an awareness of what is happening. I would suggest that a yoke whilst not making the awareness worse it wouldn't have made it any better.

So, from one source, there are now multiple sources of PMs.
Whatever the extend of the ring was, the idiotic message went around, and it seems that nobody alerted the Moderator to delegate the impersonation problem to him.

You have a problem with your parser - I said nothing to that effect.

But to help with your implying of unawareness of what was going on regarding your post, I will remind you that you were cc-ed on my communication to the moderator, so you were well aware of the link between your post, my reaction, my request to the moderator, and the removing of your post, so had plenty of info of why your post was removed.

Nevertheless you continued recently in two instances, with repeating the spreading of context of the older idiotic messages...

This is so ridiculously amateurish ...

Do you need me to teach you how to act like a computer professional?

If you don't have access to the IP addresses, the Moderator does, and if he doesn't, the WEB master does, and so you should have asked the Moderator to look into it, if you had a suspicion, and wait for their answer, before posting publicly content of idiotic PMs... .

I am glad Organfreak made this sewer detective activities public, as it seems they went and go quite a bit.... Pfew, what a stink...

The enjoying of the mambo-ing around the "if" conditional sentence is your choice...

CONF iture,
It's my opinion too.

Between visual and audio perception, the visual is a lot faster. It's not only the speed of light, versus speed of sound difference, but the speed of reaction to one versus the other stimuli to the brain.

Perhaps it would be helpful to share what race car drivers are taught:

widen the eye scan to over both sides of the track, and forward from front of car until as far as possible, and monitor any change of color, reflection, or shape that is abnormal. Upon detecting a change, focus on it, determine what it is, and react if necessary. The transition from monitoring to focus, to reaction is fractions of seconds, enough to have a correct reaction in time to avoid critical accident situations - as at the speed of a race car, in a second or two, the distance covered maybe too long....

There are two problems with that argument. Firstly, distance - at the distance in the cockpit the difference between audio and visual perception is so infinitesimal as to be totally disregardable. Understanding and interpretation are the key.
The second issue is that visual perception is worthless without a frame of reference and that is why a yoke is no more superior than a sidestick. A yoke moves - how far is a significant movement? Who decides the frame of reference?

CS 25.207(c) Stall warning: So how about: IAS >60 kCAS and AOA(highest of 3) < SW threshold?

Power+Attitude=Performance.

Or am I being too simplistic?

Causes and solutions vs justifications to do nothing...
 

In this case UAS was an incident where no intervention was actually required, just keeping Normal Law in force. With 3 A/S data loss, but knowing that A/S cannot suddenly change on large scale without a considerable acceleration being sensed , with at least 2 principle different source of data for speed (GPS, and inertial – acceleration derived ) – results that ‘simple’ changes are ‘at hand’ to software engineers for preventing pilot to be suddenly put in the control loop, when at least a warning time would be much more appropriate if not even allowing temporarily discrepancies/anomalies to be surpassed (and I am curious, in how many similar cases the time for ‘appropriate reactions’ of pilots and return to the initial trajectory were larger than duration of speed anomalies) .... .

But – no changes for speed sensors, no changes for F/Ctl software, no changes in pilot training – how many years?

And these not thinking about other means possible to develop: wing load can easily be deducted measuring strain in wing structure (using tensiometric sensors f.e.), wing deflection can easily be measured also, the conclusion is that flight being nowadays a mass service, authorities, insurers, carriers (in a word the whole industry ) treat it more and more as volume,( not quality/safety) driven.

Unfortunately , as in many other trades, the lie stay in what is not told to customer (or rarely escaped, and with smallest font written) and even to industry professionals too. It seems that remain to judges to make that policy too expensive, (but, little hope too...)

@ Old Carthusian,
The PNF's frame of reference is relative to his seat position just before the zoom climb. Significant movement is some inches before the yoke is in your chest - in your chest is excessive.

I would not disagree.
Still, IMO, the single condition AOA(highest of 3) < SW threshold would be enough to satisfy the CS 25.207(c) you did mention.

It is not much who but rather what decides the frame of reference ?
Experience, experience does that. A student pilot is already able to appreciate that half travel displacement of the yoke is usual for takeoff or landing phases but unsuited for cruise speeds.

I agree with those, with some caveats.

1/ Not sure about preventing upward trim only - you then turn THS into a control that can only ever ratchet nose-down which doesn't sound good. Maybe a fixed travel limit, but you'd need to ensure that the available range will give you all the control you need in the event you've got to a continued false stall warning. The whole autotrim area needs looking at in and out of stall IMO - too many incidents of autos trimming up into a stall and then handing the pilots the problem. It isn't going to be a simple problem with an easy answer though.

2/ I wouldn't be suprised if this was at very low level "close" to the senosrs and in hardware rather than software. Whether you term hardware issues "bugs" or not, it's a design issue (right down to what the AOA and pitot probes actually dleiver) that needs looking at.

4/ I think they do inhibit, may depend how you get into UAS though. But the switching in and out has got to be distracting and potentially confusing. Hence something with some real intelligence should switch it out and bring it back when things are properly understood and stable again. Now, what's the first UAS memory item again...


I'll also throw in another potential design issue, with the caveat that I'm also "not qualified to fully comment":

5/ the system notifies / warns of UAS, and changes control law etc., all well and good but where is that notification to the crew when the speed sensing is ok again ? I'm not sure there is anything (or nothing explicit) ? These pitot failures have been held up as transient events, lasting tens of seconds. They are being (mostly) correctly detected (but not prevented) by the built in checks and redundancy. But if the system never reports a return-to-normal, how is the crew to know ?

I believe this crew were still attempting to troubleshoot the UAS event well after it had passed, and when they should have been troubleshooting their real (correctly indicated) airspeed being fatally low.

And maybe they were trying that in the later stages. Doesn't work too well when stalled...

320 has three degree -THS limit in Alternate. As above, it is stated that the 330 DOES NOT. That is an assumption based on the DFDR related to AF447. (THS migrating to Full NU and staying).

GOSPEL? Why indeed would the logic be changed? Wouldn't it be consistent in the family? I have read it here, but not in the words of programming experts.

Who has knowledge why the debut airframe would be different in AB NORMAL LAW/ALTERNATE2 than the A330?

As has been expressed here by others, AUTOTRIM in other than expected/normal conditions is considered unwelcome. What is the genesis of AL2 AUTOTRIM past 3 degrees (-)? Especially when mindful of the family DNA.

FALSE SW defeat notwithstanding?

Not if the AoA gets the value zero for <60 kCAS.

Firstly, I suspect your making the assumption that the visual information and sound information are of same duration, which is not correct.

The visual information duration needed is a fraction of a second.
The sound information duration is the time needed to pronounce the words, perceive the words, and transpose that mentally in a mental visual image of what that means - a couple, to perhaps several seconds.

That difference of a couple, to several seconds, is not infinitesimal in my math at all - particularly when the time to take actions is very limited, measured in seconds, or tens of seconds.

With direct visual contact, a move of the control beyond a certain position is sufficient to trigger a first visual warning.

After the first visual warning the observer can perform a closer observation, which can render more accurate information.
This is were my example of race car driving practice comes into play.

The visual observer is a pilot, so the visual frame of reference is developed during training, and developing awareness in the cockpit. Time needed is a lot less than duration of training.

Using visual contact does not mean excluding other means, those means, which you're suggesting. In fact I believe using all means is a current routine practice with controls were visual and tactile contact is possible.

Which brings forward, that adding the "tactile information channel" - remove (optionally, or not) the independence - is only a plus.

With the greatest respect, OC, your argument has become centered on the relative appearance of Stick/Yoke. This difference is truly less important than the physical placement of the mechanism.

If the two Sticks were placed in proximity on the console, the argument is mooted.

It is the isolation of the mechanism, one from the other, that prevents a shared awareness of the positioning of the device, and the results commanded to the airframe.

Let's call this 'shared awareness' .....autonomic CRM.

2. "Of, or relating to, internal stimuli......." automatic.

Watching others is what Humans do best.

imho.

edit. Also, if RHS Stick went inop, and LHS was incapacitated, RHS could fly (also lefty) with #1 Stick. This would be a marked advantage even over the yoke system. Anyone suggest a place to put the trim wheels?

Coolie Hat? With Clacker?

To Sleepy:
(a request in re: DRAMA. Less, please?) The Earth has but one center.

330 vs 320 THS, Yoke vs SS, Yankees vs Dodgers (Arsenal vs United)
 

If an air data problem or some other problem results in a reconfiguration to alternate law in an A330, I would think the 'plan' would then be to continue, under control, to point B without stopping off for stall practice. At point B, as the aircraft was slowed and configured, the autotrim would function just as it would in normal law and provide landing configuration trim settings compatible with airspeed. The 330 will fly the approach all the way to 'flare law' in alternate.

As for the 320, I thought someone posted a while back that from alternate law the 320 drops into direct law when the gear is lowered which would require manual trimming on the approach anyway. I may have hallucinated this but I would bet a 320 guy will correct this if I'm wrong (which is a definite possibility) within New York minutes. :)

Why they're different, I don't have a clue. And preferable, I guess, is in the eye of bestickenholder.

****************************************************

With respect to absolute separation of LHS & RHS control input devices:

In the case of a column/wheel 'jam' (possible cable/control surface jam) in a follow-up 'connected' yoke system, the older non-FBW Boeings had both fast and slow speed electrical trim switches for pitch control thru the stab with a jammed elevator or hand flown elevator control with a jammed stab. As far as roll, they had a force breakout shear system for the right side control wheel which allowed direct control of the spoiler mixer by the right-seater for roll.

The pilot actuated electric trim (no pilot actuated electric slow speed trim in the 73) is obviously carried on in later Boeings but I don't know about the shear-out capability for the control wheel, but I would suspect there is a provision for independent roll control of some sort. Could be wrong of course. :}

OK, one more on this subject, then if you want to talk to me about this it's going to have to be via PM (don't want to derail the thread further)

Not so idiotic if you bear in mind the situation at the time, and I figured that if the mods had to be involved then the people giving me a heads-up would be doing so themselves.

And I heard nothing from the moderator other than noticing in passing that the post, along with a number of others, had been removed.

Am I not permitted to be only partially convinced? It may be a coincidence, but your language skills seem to go to pot in similar ways when you get agitated.

Look, I've been posting on forums of all kinds for 15 years. As much as I have a high regard for this place, sorting out interpersonal spats and catching sockpuppeting is considerably low on my list of priorities - if the mod team take an interest, or if someone wants to get the mod team involved, that's down to them. Also, being a netizen (eurgh) that could be considered somewhat "old-school" I remember the days when this sort of thing was sorted out between users without resorting to "telling teacher". In most cases, the mod teams are busy sorting out obvious trolling and deliberate manure-blending and don't need to be bothered about a bunch of people who've got the wrong end of the stick about something.

As for "amateurish", when I'm getting paid for something, you have my undivided attention and will receive my best efforts. When I'm taking part in a conversation in my down-time it's my own damn business how involved I want to get. If I have reason to suspect I'm being played, I take that as an insult and tend to respond accordingly

Right - let's get on-topic.

I can't find it using the search function. Apologies if it sounds rude, but would you care to repeat the question?

Anyway - a couple of minor corrections:

An algorithm is simply a set of instructions followed to take data in, perform an operation with it, and pass data out - these are the basic "bricks" of software. A program tends to consist of a collection of algorithms that perform a specific task, and would be a "wall", to continue the construction analogy. A system in software terms is a collection of programs that together perform the tasks required by the end user, so these would be a "building". Requirements are gathered from end users (in this case pilots, aero engineers and airlines). Specification tends to happen from the top down, based on those requirements, so you'd start with a system specification, break that down into the program modules required, and then each program module is broken down into the required algorithms. The A320 project was probably the most exhaustively specified software project of it's kind at the time, and I should know because I've seen examples! The algorithms themselves were deliberately designed with as few lines of code as possible to keep the implementation simple, and where the heavy intellectual lifting was required was using and combining those simple algorithms to meet the specification.

Implementation in this case involved the low-level algorithms being coded as per usual (albeit tested at a level several orders of magnitude higher than even the average safety-critical project), but rather than "hand-stitch" them together (and potentially introduce errors), the software team developed a graphical logic-tree builder to build the systems up. The individual modules were then exhaustively tested, and then each system was exhaustively tested by feeding them flight data captured from existing aircraft and also data outside the specified limits of operation in order to make sure that no logical errors had crept in. They then performed regression testing, which basically bombards the software with a lifetime's worth of flight data over the course of a few days and studied the output to see if there were any issues, fixing accordingly. This testing and refinement process alone went on for almost a year, if I recall correctly.

No system is perfect, but this one had to fall in line with aviation certification requirements, and as such the chances of failure had to fit an infinitessimally small number.

So that's a slightly off-topic ramble out of the way, just to drive home that anything that comes out of this regarding stall warning or anything else relates to the original requirements and specification, not the design or implementation.

CONF - the "IMO" regarding yokes pleases me greatly, and makes all the difference to how I read what you're saying.

That's fine theoretically, but realistically would you grab the control column or stick from your colleague without first verifying what is going on? Except in the extremest of circumstances I can't imagine that being the case. Whether you see/feel movement in a fraction of a second or a second or two via the instruments, would it not be prudent to first find out why they're doing what they appear to be doing?

While the difference may not be infinitesimal taken in isolation, in this case the zoom climb lasted for approxmately a minute before the aircraft stalled and began to descend, which gives, based on your numbers plus, say 10 seconds to confirm, at least 45 seconds to take control and perform corrective action before the aircraft stalls, and at a conservative estimate another 45 seconds while the aircraft is stalled to begin effecting a recovery before it passes through 30,000ft on the way down.

A question – to ATPLs. Particularly AB drivers and AB330 especially.

The PF’s actions to try to correct roll were described as “stirring mayonnaise” and PNF advised him to be more gentle.

If the control had been a yoke, is it likely that such extreme movements would have been made by PF?

(My experience in a glider is that one can rapidly move the stick all over the place and the glider attitude is unchanged. Hold it slightly off centre, however, and it does change the attitude. But all that, of course, is at a low mach number. I would not do it at VNE! But also, gliders do not have “protections” built in.)

Chris N (Still no agenda, still just learning.)

Dozy!
 

Not that you were addressing me, but yes...in a heartbeat!

I wonder, what could be more extreme than, "you are about to die!"? :eek:

By way of further explanation, this would be no time to be, er, polite.

Quote:
In this case, TOGA allied to 15°(or so) nose up attitude giving a massive sink rate? There can be but one conclusion, the aircraft is stalled. So, reduce the pitch attitude to unstall the wing!

Krusty is correct.

You might want to think that through a bit. Remember that it's looking like instinctive manipulation of the controls without properly assessing the situation was what got them into this predicament in the first place.

OK - so... Whether you've responded to seeing the flight controls move, or unusual responses of the aircraft through the instruments at this point you know that something's up, but you don't know what or why. Even with a traditional yoke giving you feedback you're coming into the situation cold - you don't know what the aircraft was telling your colleague and you don't have a feel for what the aircraft is doing. By grabbing the controls with little or no warning you risk startling your colleague, which is in fact incredibly dangerous and you could end up "fighting" each other. One of the advantages to the sidestick system is that by holding the priority button you can "lock out" the other stick if you need to.

This is still bad airmanship however. At the start of the climb, through the point of stall until you have had descended through 30,000ft you are not "about to die" if you keep your head about you. During that period you've got 90 seconds at least to ascertain the situation and develop a response before you're in serious danger. Politeness is certainly optional, but clear communication, knowledge sharing and correct response is mandatory. "I have control" means just that - once the callout is made both pilots have to respect it, and if that means hands-on-lap for the non-handling pilot then so be it.

Bear in mind that Captain Burkill of BA038, for example, only had 30 seconds before they hit the ground, less than a third of the time between AF447 beginning the climb and passing down through 30,000ft. In that time he managed to ascertain that his F/O was handling the aircraft well - thus taking control would be a waste of time, evaluate all the options available to him to extend the glide and get them over the fence and antennas, decide that the best thing to do would be to reduce flaps to 25 and then execute that decision. These actions were validated by the AAIB officer involved, who said he'd have given him a negative writeup had he tried to take control.

NB : I'm not comparing the two incidents in terms of airmanship or successful recovery - I'm simply using it to demonstrate that by thinking logically and remaining calm, you can do a lot in a surprisingly short time.

Could you make up your mind?

In the first quote not knowing (seeing, recognizing) the action of the PF you recommend to take over control of the aircraft, and in the second quote being able to recognize (by whatever means) the wrong input now you want to start a discussion with the PF?

That any kind of takeover control should be verbally announced is self explanatory.

franzl

Franzl,

There's a world of difference between determining something is wrong and calmly and methodically taking over control (which is what I was talking about in your first quote) and taking the controls with little or no warning in the split-second it takes you to see the yoke in a place you don't want it to be (which you'll see is the case in your second quote if you follow the conversation through).

Thank you, i see, it has to do with the special DW interpretation.

In the first quote we talked about AF447, and you recommended to take over control. The further quotes have their roots in this discussion. They are based on the assumption, that the decision to take over control (which did not happen) might have positively been influenced by the observation of the wrong SS input, hence take over of control might have happened.

But now you argue, that this observation might be not helpful, but hindering in the decision, as the observation of the wrong input and a following take over might be premature to the situation and has to be discussed before?

There are lot´s of decisions to be made within a second during a normal flight , and that would have been one of those.

You are trying to pull my leg again.

franzl

Caution: not adding anything useful to the disc.
 

Doozy said,
...zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz zzzz.................

I'm not pulling anything, I assure you.

Whether you can see what your colleague is doing or not, the decision to take control is an important one, and whether to do so or not is something that you have to think through, even if it doesn't take long based on experience to make that decision.

(You know this - I don't need to say it. Or are you simply picking holes in what I'm saying because I've annoyed you for not sticking to talking about software?)

When we were discussing things earlier, we were talking about the AF447 accident sequence as we know it to have occurred, and I was of the opinion that the PNF had a better handle on the aircraft's situation and as such, should have felt empowered to take control.

What I'm discussing with Organfreak (like me, not a professional pilot) is the consequences of taking control and that - in general - it should not be a decision taken lightly and should certainly not be rushed into if you see the control column in a place you don't want it. Even if you decide to take control quickly, the procedure must be followed and the decision must be well-made. If I've understood him right, he thought that taking the wheel as soon as it is seen to be out of position was the right thing to do, with which I respectfully disagree.

@Organfreak - very mature... :rolleyes:

Dozy,
The indecisiveness and lack of definitive action on the part of PNF killed those people just as surely as did the (apparent-- I'm waiting for the final report) incompetence of the PF. Your arguments are pure obfuscation and, AFAIC, stem from a desperate need to be right, no matter what.

I was very impressed with your careful and sober-sided analysis of the software stuff, but as far as your insistence on what is really only subjective opinion, and the utter lack of respect for other pilot's differing opinions, makes me feel that the most appropriate response possible to all of your nonsense was, and still is:
zzzzzzzzzzzzzzzzzzzzzzzzzzzzz............................... ..
I have little doubt that almost everyone else's eyes are glazing over at your single-minded contrariness!
Other than that, have a great day! :)

Dozy, the algorithm bug that has been discussed at some length is why, below 60 kts, stall warning is curtailed even if one is stalled and weight is off the main mounts and main mounts are retracted and stowed.

That would be an algorithm bug raised in this incident.

Not sure what else, other than the algorithm used in the AF training and currency policy, given what appears to be not one but two instrument scans that were behind the problem from early on in the problem. (Refer back to PJ2's varoius posts on how this ought to have played out if you like).

There also appears to be evidence of a CRM regime that leaves me scratching my head, which may also be an organizational algorithm/decision tree sequence that could use some tweaking.

Insofar as software algorithms ... the one cited in re SW makes no sense to me.

For Old Carthusian: With respect, not quite. *

Your instruments reflect the outcomes of flight control (primary and secondary), power, configuration, and environmental effects on the aircraft.

While this is mostly a reflection of flight control input (particularly in a constant power scenario) your instruments don't do what you say they do.

I've seen your later retraction, but would like to point out (for pilots it's obvious) to non pilot participants the issue of power/attitude/configuration ...
which is what the pitch and power chorus have been on about since June 01 2009 ...
and which is where some fundamental flying basics seem to have been forgotten in one particular cockpit. :uhoh:

Why?

I sure hope BEA comes up with a good answer.

* = FWIW, I first got my first instrument rating in 1982. That doesn't matter at this point. Instrument scans and performance on the controls tend to atrophy when not used with a certain frequeny. I'd as likely as not kill all souls on board if, this afternoon, I was forced to fly to mins in dodgy weather on instruments with crosswind limits at the edge ... unless I remembered to wave off when the approach got too hard to handle ... waveoff is Navy speak for "go around" of course. :cool:

Rust never sleeps, but I hear it can kill.

OF is correct.
Sometimes, there is not a split second to lose.
In Hamburg if the PNF could have seen the inputs applied by the PF during the flare, he would have jumped on the controls, with immediate effect, and for the good of all.

Quote:

---

If I've understood him right, he thought that taking the wheel as soon as it is seen to be out of position was the right thing to do, with which I respectfully disagree.

---

Dozy, with respect, in some situations it is mandatory, and sooner rather than later. Entire curricula are devoted to such things in CRM training, multi place pilot training, and training as an instructor pilot.

Sometimes, just take it, fly the plane back into its performance zone, then talk about it after all is settled and you are back to straight and level, or back on the ground.

Other times, talk the other pilot back into the box.

It Depends Upon The Situation

I have done both. I have had a plane or two taken from me as well.

In a few of above cases, more than one life was saved.

Had some Real Close Calls in between.

Not so fast. We do not know what exactly PF saw on his panel. Hence we do not know the stimulus response record. If it differed from PNF's screen, he may well have thought the PF's stickwork...odd. We do not know how the a/c was behaving, precisely, especially in relation to the instruments of BOTH pilots.

What we "see" are results derived from inertially driven and recorded data, NOT WHAT THE PILOTS SAW.

I believe the a/c was quite active out of autoflight, and absent decent instrumentation, the Pilots struggled from the beginning, and never caught up.

It is ASSUMED the PNF was the one with the picture, I submit that is not possible to know: it only seems so after the fact, and with data that was unavailable to either of them at the time.

Bottom line: The climb was commanded by the Computer, by definition. Giving the pilot what he asked? It seems that way, but think.......

Only if the pilot KNEW he was climbing does he seem 'incompetent'. If he was reacting to an attitude that did not reflect reality, and his PNF did not notice, he was controlling the a/c, period.

How did the a/c reacquire airdata? Did it? With 40-60 degrees of AoA? Rolling Right/Left through 80 degrees? Attitude from ISIS? Roll cues from ISIS?

Can anyone else put together the degree of UPSET on the way up that may have contributed to PF's falling waaay behind? I think there was plenty, in no way did he start from Straight, Level. And he had to start quickly.

Lyman, the CRM issue is that pilot suffering instrument failure declares

"My instruments (instrument) are (is) AFU"

response is by the other pilot

"mine are OK, pass me the controls"

or something like

"you are left wing down, roll right, stop roll
"your nose is too high, lower nose, stop your nose there"

and such other verbal input commands to fly the aircraft back to straight and level flight. But then, PNF needs to have his instrument scan up and running to be helpful like that ...

What appears to have happened is that an assumption was made that some instruments were running amok, and PNF switching to a differernt gyro feed would resolve that problem. But as not much was verbalized beyond that, I remain uncertain what PF saw on his displays.


I think we've talked about this before ... :cool:

I know it sounds like I'm being pedantic, but this is not an "algorithm bug", it is a specification that, with hindsight, needs revisiting. I suspect that if you dig into the design, it is not that stall warning is intended to be curtailed under those circumstances, it is because the sensors that provide the data cannot be considered reliable below that airspeed, and so the data as a whole is discarded until the circumstances make the data valid again (which is borne out by the return of stall warning as the speed picked up). The best and simplest solution I can think of is therefore to latch the current stall warning state when the data becomes invalid, and unlatch it when it becomes valid again.

@Organfreak - it's got nothing to do with being right, it's to do with the fact that left to their own devices we'd have "yokes r teh awesoem, sidesticks drool" from the same four or five posters over and over again with no dissenting opinion. I respect pilots greatly, but it doesn't mean that they're always right, nor does it mean that one should genuflect before them by rote.

@CONF - Or you could have had a split elevator condition (as in EgyptAir990) and a nasty crash.