airtren

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.

Lyman

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.

OK465

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.

DozyWannabe

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.

chrisN

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

Organfreak

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

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

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

Neptunus Rex

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.

DozyWannabe

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.

RetiredF4

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

DozyWannabe

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

RetiredF4

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

Organfreak

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

DozyWannabe

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

Organfreak

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!

Lonewolf_50

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.

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.

Rust never sleeps, but I hear it can kill.

CONF iture

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.

Lonewolf_50

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.

Lyman

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.

Lonewolf_50

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

DozyWannabe

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.