(is the bit immediately before...)

This was discussed in the first thread very shortly after the accident.

As was pointed out at the time, 20kt is only 10m/s. I say "only", as many glider pilots will be familiar with benign - if somewhat exciting under a paraglider! - climbs of this type at low levels. On a decent, post-cold frontal day in the UK - not exactly known for the relative strength of its thermals - it would be disappointing not to get climbs of 5m/s under small, perfectly benign, 10 minutes later they're gone, fluffy little white cumulus clouds. If "updrafts are usually strongest in the upper troposphere compared to lower levels", then 20 to 40kt seems quite a conservative estimate.

It would surprise me - and I suspect most glider pilots - if you could find any self-respecting cumulonimbus that *didn't* contain updrafts of at least 20kt.

EDIT: Note that I am *not* arguing that a strong updraft caused the zoom climb or had any other bearing on AF447, merely re-iterating, for the benefit of latecomers, comments made a long, long time ago on the above analysis.

There is evidence of turbulence - I think it caused the "stall warning twice in a row" shortly after 2:10:05. There is evidence of the absence of a strong, sustained updraft that "pushed" the airplane up to FL380 before 2:11:06 - see below.
Precisely. A strong, sustained updraft would have been evident as an increase of the total energy of the airplane. On the contrary, there was a slight decay of total energy up to the point where the airplane stalled. Another poster on this thread has correctly explained that decay as the result of thrust reducing with altitude and increased drag due to manoeuvering airloads.
Not so. The gain in altitude is entirely consistent with the loss in airspeed, except for the decay discussed above.
Agreed, and on the AoA trace, and also small-scale turbulence would appear as "grass" on those traces, provided the sampling rate is high enough. These can be separated from changes due to control inputs by looking at the traces of elevator and THS position, and sidestick positions.
If you are referring to my reply to BOAC, I didn't say that the FCS filters loads. I was referring to signal conditioning that suppresses high-frequency content of, e.g., the AoA signal, before it is passed on to the consumers.

Thanks for your reply.

I wasn't referencing your reply to BOAC on the matter of filtering out the loads imposed on the airfoils by factors outside the flight control system (Turbulence, etectera).

I was more of less "thinking aloud" based on some of the block diagrams of the flight control system, and considering how the installed stability functions (In normal or alt laws) would first sense, and then account for inputs to the system from outside the aircraft, as opposed to adjusting for inputs from within the control system.

DJ77: thank you. :) Re-reading that got the point across.

Caveat: the assumption that the air mass data (airspeed/Mach) were not already beginning to degrade by that point, but it seems a safe assumption based on when alerts and miscompares show up on the record.

HN39: "The other illogical element in my view is that alpha-prot law is not cancelled when AoA decreases below alpha-prot. Again I suspect that that choice has been made after intensive investigation of all the "what if"-s, but you have to ask the designers."

Perhaps it is a naive question, but why is there not more information available (public domain) about the choices made by the system designers, so that certain excellent questions raised by HN39 and others can be better addressed? I understand that there may be proprietary matters at stake but in other industries, such as my own, critical safety-related matters are fairly openly disclosed/discussed. The regulators enforce it, for one thing. Is there no technical journal in which such matters can be presented and discussed? If there is such a journal, is it serving this purpose to the full?

Anyway, I'd like to thank HN39 and others for so patiently and clearly explaining their thoughts on the matter - I speak for many who are learning a lot about Airbus detection and control systems in this thread.

Please carry on.

"AAIB Bulletin No: 6/2001: Consequently, in turbulence the speed scale will probably be oscillating, the aircraft pitch angle could also be oscillating..."

if the bird flow for sume time nearly in a balistic curve, the AoA vane is in a stable normal position... no AoA protection will start working

AoA protection alone seems not very good for stable flight

the climb-input is interesting, after the stopp of the autopilot they moved the elevator up to +4 for ten sec. but in the following seconds the G falls to 0.5 and the pitch drops a little down (!) IMO this needs good downwind. then they hold the elevator between 0 and -3 and pushed the 4 engines this must be the climb-input, mayby together with the autotrim

ar you shure AoA reached alpha max? nighter the trim nor the AoA is shown in the diagram. the climb after the startinput could also happen with a lower AoA....

@SDFlyer - There are plenty of links in this thread and the previous ones to Airbus documents that describe the various systems and mode reversions, along with the logic that triggers the latter.

Am at work now, so can't hunt them down myself, but they're there. I think the one you're looking for would be called "Airbus Control Laws".

That whole statement seems to imply a much wider bandwidth and shorter time constant for a mechanical AoA sensor than ever likely. Also implies that anyone would be interested in small scale high frequency turbulence... that would be for a hot-wire anemometric device if we're into the business of looking at 'gustiness', which I'm pretty sure we aren't

I don't think anyone is suggesting that.

Transient overspeed in turbulence prompted the crew to close the throttles.

As speed reduced, turbulence then caused transient increase of alpha to exceed alpha-prot (or the predicted trend to exceed it), this engaged the alpha flight mode such that the neutral sidestick would command alpha-prot (and fully back, alpha-max).

If this is activated by a transient high alpha value, then when that transient effect goes away, you will get a climb. Alpha-floor then probably kicks in to increase the thrust after the pitch up.

Ah, but under what circumstances ? Like all safety engineering, in some situations this feature will do the wrong thing (in others it can save you). Sometimes the only survivors are those thrown clear, sometimes it's only those who are belted in - so should we have seatbelts or not ?

Maybe this law should never activate in turbulence in cruise, but on the other hand if it had activated on 447 (which it didn't because normal law had been lost) then it would probably have avoided the stall. Or consider if the A340 crew in this case had been the ones to get "climb climb..." from TCAS

At the weekly Old Bold Pilots breakfast this morning, I asked the guy who was cognizant engineer on the stall warning computers for the DC-9 and MD-80. He was incredulous that the A330 Stall Warning would shut off below 60 knots airspeed. He said the AOA vanes on his planes would measure to about 50 degrees AOA.

I suspect the A330 vane mechanical limit is about 30 degrees, as I don't recall any greater AOA mentioned by BEA. Does anybody know?

There is a much stronger argument against updraft and that is energy conservation.

Decreasing speed from 275kts to 215kts IAS at the apogee equals roughly 4100 feet altitude gain from an equal energy perspective.
Taking into account that there are some drag losses due to g load and roll the 3000 ft climb match excellently to the altitude gain to be expected by trading speed for energy based on the given data points.

Had there been an updraft the energy level at the apogee would have been higher.

Ah well. You see what you see, I guess.

"If this is activated by a transient high alpha value, then when that transient effect goes away, you will get a climb. Alpha-floor then probably kicks in to increase the thrust after the pitch up." - That's really clever - when you inadvertently pitch too much, the system ensures you stay pitched too much. A climb no-one wants or needs - thanks AB!:mad:

God help us all.

As noted above, it's a compelling argument providing the IAS information we are working with is accurate. Given "ordered" airspeed and "what it takes to stall" the measurement anomalies seem to wash out.

@BOAC, in re God help us all ...

Doesn't this take us back to why you must have humans on the flight deck and in command? The PIC must be in a position to override discrepant subsystems.

Systems will go squirrely.

That said, I agree with you that this particular feature might profit from some rethinking. Having read what you responded to, it makes no sense to me for this feature to be enabled at high altitude cruise. The feature appears to be primarily designed for flight regimes near to the ground.

Now, I am all in favor of FBW; it simplifies systems; saves weight, and increases efficiency. But, why did the engineers not just make it fly last the last 100 years of aviation. Speed stable (trim for a speed), back-driven so the pilots know what is happening with the stick and rudder, no obscure modes that are confusing in an emergency.

Oh, Boeing did that!

FBW + Airbus SAS "features" (testability issue)
 

GF, Hi

:ok:


:D

The "features" sometimes creates problems. Who will change that?

The "problems embedded in the features" could be eliminated?

It´s possible to identify it in the design? Could be testable?

@GB:
 

- Operating Range 120º, limited by fixed stops.
- Balanced (= static it could take any position).
- Contains a dual purpose damping motor, damping the rotor in opposite direction of movement
created by Eddy Currents with a torque proportional to the speed of rotor movement, with a breakout force of 0.04 Nm.
- Damping motor can also be used on GND for test purposes (positions AOA sensor in a pre-determined test position)
- Internal heating element 115 VAC, 400 Hz; operating temp. 120ºC.


LINK

BOAC is a really good chap but, unfortunately, has not enjoyed an Airbus type rating course.

He will soon I'm sure but, in the meantime, let us forgive his neandethal mutterings.

sorry mate.

Hi,

It's no doubt (for pilots and general public) that the Airbus airliners are very sophisticated aircrafts stuffed with modern technology materials
Now .. the question is ..
Sophistication = simplification ?
If the answer is NO
Why it's seem's that many airlines have not very sophisticated programs of formations (schooling) and high training for their pilots ?
How it can be that a general opinion is that in general the training and formation are on the down slide .. and in the same time .. the aircrafts are on the up slide of sophistication ?
And what is the response of the officials bodies for this ? (regulators .. laws makers ... etc ..)
It is now the aircraft industry corporates and banks who are regulating the air transport ?

Sorry but, in that perspective, a type rating course won't teach much. Only regular, repetitive, and studious incident/accident report readings can help to realize that nothing is that simple in the Airbus world. Every report brings its part of discovery ...
This is not only true for the pilot, but probably also for the designer himself ...

Do you know how the 120 deg are distributed, is it +90 -30 ?

Software Engineers will tell you its Abstraction. You don't need to know how the transmission works to drive to work everyday.

The bean counters will tell you its statistics. How many times have you trained for brakes in you car giving out at 60+ mph on the highway?

Ironically, "Simplicity is the ultimate sophistication" was an early slogan for Apple Computers.

Because at some point the training wheels have to come off. If everything was made to work "just like the old days" this board would be a complete pig to use!

Put another way, Boeing made the 777 to simulate a feel similar to that which Tex Johnson had in the Dash-38. Airbus made the A320 FBW series to feel similar to the equipment the Apollo astronauts used to land on the moon. The methods are *different*. Not better, not worse, but *different*.

I don't understand what's so confusing about "if in Normal Law rely on the protections, otherwise do not and apply more caution when making control inputs". We don't even know if all this round-the-houses about what does what in which law applies in this case anyway. We know the pilots were aware they were in Alternate Law and we know that the PF made some control inputs that on the face of it make no sense. All we don't know is why - but it seems a select group have already decided it must be the computers' fault, despite the fact that they have no more information than those who are advising "wait and see".

What has Software Engineering got to do with whether someone knows how the transmission/gearbox (for us Brits) on their car works? I guarantee you that the majority of drivers wouldn't have a clue (and I only know in general terms). Furthermore, abstraction is something that has happened in aviation ever since someone hooked a pitot up to a pneumatically-driven dial. That dial was abstracting the raw information from the pitot tube via a mechanism that translated that into human-readable form. Some of those mechanisms were very much better than others!

Aside from the fact that, as I've said countless times, the software that runs on aircraft is only a gnat's chuff comparable to what you and I use on our PCs every day, personally I've always considered Apple guilty of what the naysayers here are saying about Airbus - i.e. deliberately obfuscating the workings of the system - in their case to enforce dependency on their retail chain to fix problems.

The difference is that it takes a far lower grade of technician/systems administrator/software engineer (i.e. me) to understand what's going on in a PC or server (which - let's face it - these days is usually a PC) than it does a safety-critical real-time system like those plumbed into aircraft.

I've been watching all the threads carefully.

Nobody seems to have mentioned the pilots turning on the landing lights and watching the ice, snow, hail, and rain going upwards. (pilot, and engineer).
.

@BOAC:

Well, inadvertent pitch up is always going to give you a climb you don't want/need by definition - and it only "ensures you stay" until you tell it to stop.

For every safety measure you can always find a scenario where it will be bad for you. If you are asking "will this ever possibly kill someone" then you are asking the wrong question.

@Lonewolf:
Agreed, and if I understand it right, it is one of the things that gives AB superior GPWS escape capability. On the other hand, it has acutally caused one crash on landing (which is near the ground...). The activation logic has changed as a result.

Clearly if above 30kft, we shouldn't be needing a GPWS escape, so maybe disable it. Then what happens if the plane has dodgy altitude info ? Ah, but what's the probability of needing a GPWS escape and at the same time the altitude being screwed ?

[ Bit like what's the probability of grid power at a major power station being down for several hours and there being a tsunami at the same time... (think about it) ]

No easy answers, and the events are so rare it can be decades before you get a clue if you made the right call.

@galaxy flyer
You know, I admire the boeing backdrive, impressive feat of engineering - but there's still a nagging doubt that it's added a whole lot of complexity, and hence failure risk. All to give the pilots a "feel" of something that hasn't acutally been there (ie. direct cable control) for decades. That "feel" is something you want most when things go wrong, but, you know, it's precisely when things are going wrong that you shouldn't trust it - because it is purely artificial and is calculated using the same airdata, config etc. information that may be what is going wrong in the first place.

The backdrive has limits (soft, not hard, but there) - if the a/c is flying on bad data, those limits will be in the wrong place. I am also pretty sure it will use airspeed etc. in calculating gains even within the limits - lose airspeed and are you sure the feel is going to be "right" ? If it's dark over water and your instruments start acting up, and the autos drop out, are you going to start flying the plane based on that backdrive feel - even though it's being calculated from the same airdata that you know is screwy ? Is that better or worse than "no feel" ?

And, of course, the backdrive is modal too - or at least sometimes it can cause "higher than normal control forces" in a way that is, as you say, "confusing in an emergency". But that's ok, no one's died so far, and there's an AD for it now - a software fix to make sure we don't activate that mode at the wrong time. That sounds so very... airbus, doesn't it ? [ But I'm sure you B fans will know the AD and I don't have to dig out the reference, right ? :)]


It's an imperfect world, A or B side, fbw or non. Both fbw are very safe, but also very different. Feel free to have a preference as to which is nicer to fly, but as to which is safer to fly in - I don't believe there is anywhere near enough data, and too many variables, to separate them.

My naive (non software literate) attempt at defining the SE concept of abstraction. Nothing more. But lets face it, even if he/she needed to, what chance has a pilot got at understanding what goes on software wise on one of these a/c?

Unlike understanding the abstraction at work in guages that you describe, which helps me be a better airman (in case of, say, pitot blockage), understanding the voting logic of various computers does nothing for my airmanship.

Inherently false.

Question should be does the increased sophistication result is a system that is less prone to failure, or more prone to failure.

The overall "system" is aircraft + pilots. Maybe as the engineers have sought to decrease the failure rate of the aircraft, this has lead to airlines dumbing down the pilot side of the equation to reduce cost but keep the overall same level of risk.

Note that this amy not be a concious decision, and the effects might take many years to notice in the accident stats.

Commercial flight has to be at both a profit and an acceptable level of risk - or it will not happen. It has always been that way, and applies to most if not all industries, not just airlines. There will always be an element of commercial feasibility in regulatory decisions - otherwise you risk regulating the industry out of existence.

In the absence of an aviation regulator that insists on highest possible safety at any cost, you can always choose not to fly. The effect is the same.

Let's be honest here, what percentage of pilots in the steam-gauge era knew - and I mean really *knew* - exactly how the mechanical and pneumatic systems were translating the data? What the tolerances and ratios were, what every possible failure mode looked like, the whole shebang.

This is just an opinion mind, but I'd say it probably does in this day and age. Airmanship is about knowing your craft and having a healthy amount of aeronautical knowledge to back it up. Arguably these days it also includes the art of delegation if you're in a senior position, and how to be the best member of the crew you can be regardless. Understanding the systems to the best of your ability fulfils the very first thing I mentioned.

As far as Software Engineering goes, what is involved is no different than any other type of engineering discipline, it's just that you're dealing with instructions on a microprocessor rather than building a bridge, designing an airfoil or designing a circuit.

Going back to the first point, I'd say that it is no different understanding that the air sensor output goes through a transducer and is converted to a digital value than it is knowing that the air sensor output drives a needle round a gauge via mechanical means. It's not the most in-depth knowledge, but it's enough.

Hi,

Indeed .. not noticed
Maybe the pilots had to play with others buttons or "Humor mode open" they were afraid to dazzle those who could be facing "Humor mode closed"

Hi,

It should be noted that this system was adopted by Boeing cause the express request of pilots

Hi,

More you add systems .. more you have chances of problems or failures.
More we are ... more fun !

Hi,

Seem's we have already enough statistics from a long period of time ...
The stats are:
+ - 70 % accidents = pilots errors
The other 30 % can be attributed as human errors (bad maintenance .. bad materials .. bad systems or designs ) and some act of God.

So .. the 70 % ( the most cases) can be reduced at least by schooling and training

Edit:
BTW .. all Airbus accidents so far are due to pilots errors :eek:

Just as pilots were involved in the Airbus design process - is there a point to your post? All this means is that different pilots prefer different things - it's not like the Airbus FBW flight control system was designed in a vacuum by engineers and bean-counters.

Hi,

French//US different culture maybe ?

Yes, different cultures. I'd wager there is a lot higher percentage of Boeing designers flying small aircraft on the weekends.

Avoid cb's
 

I’d like to throw in my 2 cents of input.

We have a triply redundant system of pitot tubes which all failed at the same time. Of course using the very same systems.

Which provide info to the incredibly sophisticated computers which all seemed to fail at the very same time.

Giving the pilots nothing to see on the outside and nothing reliable to see in the inside of the cockpit,

And all of the systems that were designed to prevent stall, high angle of attack, and every other kind of protection failing to do so,

And giving the pilots no guidance whatsoever what to do about any of it,

And after months analyzing what went wrong unable to come up with any solution whatsoever on what the pilots or the auto protection were supposed to do or what they did do,

I would say that had the pilots avoided this thunderstorm in the first place we would not be talking about this.

After 32 episodes of triple redundant system failure – I would say we have here a very very fragile and weak system.

The solution to me is simple, until this is all figured out I’d suggest avoiding thunderstorms.

I tend to agree with CogSim’s comparison whether semantically, technically or practically correct or not.

I flew a FBW SS fighter aircraft among other aircraft. I never really cared much about what, software-wise, those control surfaces were doing out there banging about as long as I was getting what I expected out of the aircraft while adhering to my responsibilities manipulating the SS.

For “simplicity”, I preferred to think of all of those various control surfaces as, “wish-erons”, because the aircraft gave me so much I had always wished for, but couldn’t get, in the previous non-FBW fighters I had flown.

Software engineers are on the ground writing code; I’m in the air (simulated now for this old guy) basically ignoring it. Both sides are successful. Pilots fly aircraft, not software.

It’s a given, however, that the automatic transmission/gearbox should function properly every day, but if it doesn’t, it’s not a big drop stepping out of the car.

Incorrect. All the indications we have so far imply they behaved exactly as designed to when an air data failure is detected.

Hi,

It's also not a big drop jumping out of the plane ... provided you have a parachute :)
It should be noted that as presumptuous as usual .. man was able to invent a way to rise into the air .. but it took many years to admit that his invention was not perfect .. and he resigns himself to invent the parachute .. and it's some help when it open correctly ........
Failure finally admitted :ok:

DW

Yes, no doubt, the triple redundant FBW worked exactly as the engineers designed it, but PILOTS were flying the plane. The pilots clearly did not grasp what the computers were trying to do, probably did not understand what the THS was doing and how that might have impacted their recovery attempts, and how they may have reacted properly.

Unfortunately, pilots learn to fly on planes that fly like all the planes built since the Wright Flyer, version 1908, not like Airbuses. There have been a disproportionate number of LOC accidents/incidents in Airbus aircraft. Since the A320 Habeshiem accident, there was the NAT incident, the Australian incident, the Perpignan crash, amongst others.

Ridiculous design (AS issue)
 

I.e. BADLY! This redundancy implementation is USELESS specially at "cruise FL". Or worse, creating a CRTICAL design.

The use of a "voting scheme" capable to "major a/c reconfig" using identical (sub heated) not adequate Pitot´s is a direct path to PROBLEMS!

The System design managers that accepted this as a reliable System (fault tolerant) from the engineering team IMO DID NOT realize the OVERALL SYSTEM (aircraft+pilot) departed from the VERY IMPORTANT "graceful degradation" goal. It seems "bit oriented Engineers" concerned (absolutely justifiable) with computer systems (obviously requiring redundancy) induced to a "concept error" wrt to the AS measurements; To Project managers concerned (absolutely justifiably) with the importance of AS measurements for this design.

This a/c design IMO (wrt AS) is flawed in:

1) Ridiculous AS sensors redundancy (useless)*
2) The use of this voting scheme to not adequate AS sensors (sub heated)

Note: IMO this design EXACERBATES Pitot´s icing susceptibility


* Exception at TMA FL when one may mention chances of birds collision. I am not considering Pitot heater failure. We can discuss this aspect later.

Who can tell me why they implemented this redundancy in respect to AS measurements? I would like to understand the reason.

AF delay in replacing Pitot´s obviously contributed (to Murphy Law:}) but is not as serious imo compared to Airbus SAS (and Certification) failure.

It seems to me (as a technician) that the bureaucrats are in charge. And the pilot´s being informed they are using a redundant, etc. (advanced design).

I hope for a review of this issue (in every "advanced a/c") using this. Even with super heated Pitot´s i never would adopt this.

Auto-trim discussion
 

There has been a lot of talk about how the auto-trim system trimmed to the nose up limit and how this might have limited the control authority for recovering from the stall.

One thing puzzles me in the discussion. My reading of the BEA release is that the pilots did not attempt to push the nose down (apart from apparently brief nose down inputs around 2h12:17). So the trim position and the auto-trim function was not a factor -- it might or might not have become a factor if the pilots had reacted differently, but it does not seem that it was.

Do other people interpret the BEA report differently on this point?

Not seeing the wood for the trees.
 

Yes, probably an outlier because AF447 came down in a deep stall, with a slower descent than for a spin , spiral dive, or the like.

It might be interesting, and possibly useful, to examine these ten accident reports and compare the situations at the start of each of these events, e.g. how many of them STARTED with a disconnect of the AP?