Perfect then, let them bring the AoA to 17.5 deg.
Thrust + alpha max = PERF ... as advertised by Airbus themselves, just what we look for after all.

Hudson
 

We can start all over here ... but a good deal of it has already be done there even if the title does not necessarily reflect it :
http://www.pprune.org/rumours-news/5...-problems.html

Hi,

So, does anyone has an answer to CONF iture? I don't.

The question, as I understand it, is: why the A320 FCS didn't immediately reach for AlphaMax (17.5° AoA) in the specific AoA protection mode?

My guess would be that the software keeps a margin to avoid being in a position where the aircraft will lack down-pitch authority if needed (to avoid busting the strict 17.5° limit, that would lead to risking stall).

If correct, is the apparent 2.5° margin (in Habsheim's scenario) consistent? Isn't it too much?

Phenomenons that could explain the margin (non-exhaustive list, feel free to complete):
- Phugoïd and/or any sort of longitudinal aerodynamics-led unstability?
- Diminishing IAS?
- Provision for engine-led pitch up (throttling up)?
- ... ?

My questions would be more like :
1-Why the FCS limited the AoA to alpha prot when the request was for alpha max ?
Or why the elevators did the opposite of the sidestick displacement ?
2-Why BEA + Airbus sat on the question ?

Is it any reason to use that nickname ? It may be surprising, but the true name of that alsacian french airfield and village is Habsheim and must be said habs - heim ;).

Fair warning - now you're very much on my territory, and I can tell you categorically that what you have posted above is absolute nonsense.

Computer Science methodologies were used for every aspect of the initial specification, but I can assure you that the engineers went even further - because pure CS processes as they stood at the end of the 1970s would not be sufficient to provide enough assurance in a system requiring this level of safety and reliability. It was therefore easily the biggest and most thorough application of Software Engineering and Reliability principles in Europe at the time, if not the world. And where existing practices weren't quite up to scratch, they extended those practices and invented new ones. Multiple implementations, regression testing, test-driven development and automatic code-generation along with manual review processes were all used, and in some cases pioneered, with this programme.

Have a look at my late Prof's visit (made in 1993):

Report on visit to Airbus Industrie - 28-29th Jan. 1993

Extract:

Test pilots and pilot engineers were involved in every step of the development and testing process, and no software spec was signed off without their OK - so your claim of "unresponsible [sic] engineers" working in an ivory tower is not just incorrect, but bordering on libellous.

[COMPUTERGEEKSPEAK]

I think that then, as now, there is a significant gap in understanding the significant differences in approach to safety-critical real-time software compared with the better-known imperative programming methods that your research department was using. For example, Truth Tables are a practical proving method when using formal methods to define a single-threaded function - but in real-time systems made up of a network of finite automata, the algebra is too complex to render in such a simple form. Hence while truth tables may be used to prove low-level binary functions, a set of more thorough and more engineering-orientated testing strategies must be used.

The fundamental difference between what most people understand regarding how computer programming works and the nature of real-time systems is that in the latter there is no such thing as a "main" loop from which procedures and functions are fired - instead you have a network of finite automata modules that are constantly assessing each other.

The idea that somewhere in the code there's a function along the lines of:

IF STICK_Y == STICK_Y_MAX_UP THEN PITCH_UP(MAX_ALPHA)

is a fallacy. Instead, you'd have tens of these finite automata modules cross-checking each other, and based on the constantly changing values in real-time, they'd be configuring the flight surfaces to provide optimum response to the command inputs while taking into account what the aircraft is doing.

For example, it would do no good to set pitch attitude to match an AoA of 17.5 degrees based on the current airspeed if, by the time that pitch attitude was reached, the aircraft was flying a few knots slower.

[/COMPUTERGEEKSPEAK]

In fact, just as mechanical technology pioneered in the aviation industry tends to make its way into more commonplace things (e.g. antilock brakes on cars), the software and engineering processes pioneered during the development of civil FBW have been filtering into more general software development over the last decade or so - particularly continuous integration, regression testing and test-driven development.

Simple, it didn't. What the EFCS provided was the maximum alpha it could based on the aircraft's orientation and status - which was changing constantly. The deltas in airspeed indicated that the aircraft was *slowing down* right up until the last second, so I'd suppose the pitch angle was calculated to match the airspeed based on that deceleration trend, given the inherent delay in actuating the pitch angle to match 17.5 degrees of AoA in a few seconds' time.

If the aircraft's airspeed was consistent and stable - or indeed if the aircraft was accelerating - at the time the full backstick command was given, then the EFCS would have been able to attain 17.5 degrees from that stable value much sooner.

Here's a properly-flown Alpha Max demonstration in a Cathay A330 for comparison (approx. 0:18 onwards, though it's useful to see from the beginning to establish speed comparison from take-off):


As you can see, when the approach is flown correctly, speed is stable and approach power is maintained (i.e. the engines have not spooled down), then the systems will quite happily provide and maintain 17.5 degrees for as long as desired. All the tests flown regarding Habsheim matched the aircraft's trajectory (i.e. slowing down with late application of power), hence the significant delay in achieving Alpha Max.

Already answered. See my posts #150 and #176.

Sidestick commands rate in Normal Law, even in High AoA Protection mode. Aircraft was at maximum alpha based on the projected airspeed with the current rate of deceleration. Like a human pilot, the EFCS uses deltas and trends to stay ahead of the aircraft. Until the engines were producing enough thrust to bring the airspeed up (or if the nose was lowered to build up a little more speed sooner), then the EFCS would be basing its calculations on the rate the aircraft was decelerating.

The elevators were probably commanded nose-down to arrest the pitch-up tendency from the engines, and until the deceleration trend was itself arrested by increased thrust, that was absolutely the correct action for the scenario - indeed, the Airbus test flight which re-enacted the scenario demonstrated this, with optimum alpha max achieved once the airspeed was stable and increasing.


Again, they didn't. The data linked in earlier posts that was released by Airbus (was it in 1995?) was originally performed as part of the investigation by the BEA. The re-enaction of the flightpath at Toulouse (presumably at the expense of either the French civil service or Airbus) was part of that original investigation, and Capt. Bechet (head of the investigation) was personally involved. I don't think you could reasonably say that was "sitting on the question".

DozyWanabbe,
Thank you for that worthful report. I have to agree that it does not comply to an ivory tower.
But accept that such work quality, such teams have been in work in AS & others (the same companies) building the fabulous Ariane501 launch and crash for 8 billions FF : only one bit was wrong (the famous carry) coming from only one unuseful variable BH imported from the former ArianeIV on the ground. That story showed that reliability must get much better in softwares. Jacques-Louis LIONS had been the head of the CNES (maîtred'oeuvre) but could not see the hidden bug from his office, and discivered it only when he was the President of the enquiry Board.
I know my position is harsh, strong, strict, etc. I will not change a comma.
The fact that I am an (retired) airline pilot too is an obligation to save lifes of my colleagues, not probability of live.
Thank you to allow that open discussion.
HAPPY NEW YEAR,

Same parent group, but categorically *not* the same company, let alone same team(s). Don't let the common nationality of some of the people involved fool you into thinking there's a common problem.

For one thing, I think that all bit-depth conversions performed in the Airbus EFCS software come from generated code (i.e. thoroughly tested repeatedly and regressionally). There are no "low-level" code changes of that nature allowed using the Airbus process.

It's not that your position is any of those things - what bothers me is that your (vehemently stated) assumptions were incorrect in this case.

All well and good, but let's be clear - the number of line incidents involving both Airbus and Boeing FBW types that can be put down to a syntactic or logical (code-level) error in the computer code is zero - I repeat, zero.

The few issues that have transpired have always been down to assumptions made at the design level (and signed off by pilot engineers) which turned out to be either incorrect or incomplete, as was the case before digital flight control systems existed.

For one not familiar with COMPUTERGEEKSPEAK, it would seem that that statement is open to question.

From the ATSB Final Report on the inflight upset accident in flight QF72:

Indeed, which is the reason I book-ended that section in my post - I'll do my best to elaborate.

At code level, a syntactic error is one in which the rules of the programming language itself are violated, thus causing the program to stop running. When a program is compiled into object and machine language, these errors are usually flagged, halting compilation and resulting in no working output. A code level logical error is one in which the syntax is correct, but the code's behaviour deviates from the specification and design.

The issue you raise from the ATSB report on QF32 [EDIT : corrected from QF72 - my bad] falls into the category of spec/design-level errors, as I said:

in which the code implements the specification and/or design correctly, but the spec or design itself (signed off by the aero engineers and pilot engineers - not just the software engineers) was at fault.

This is a very important distinction to make from my perspective - because strictly speaking this is not a "computer" or "software" error at all, but an engineering problem. Not that the media will hesitate to report it as a "computer error", which, needless to say, grinds my gears in much the same way as yours when you read a sentence like "the wing flaps which help the aircraft land".

Of course I can, as the only reply from Bechet was :
"That's the normal functioning of the aircraft, and the normal functioning of the aircraft is not detailed in the report."
You can write as lengthy posts as you like and proceed with your suppositions ... you simply don't have access to the lines of coding. Airbus has, but how embarrassing is it to admit that a direct command of the elevators was more adapted to save the day than a complex inefficient design ...

Which would be a total waste of the available thrust.
Thrust + alpha max = PERF ... as advertised by Airbus themselves.
What don't you understand here Dozy ... ?

Hi CONF iture,
I agree.
However Alpha Max is approached asymptotically and with full back stick will require some time before it is achieved.
Are you really suggesting that despite the Alpha floor being disabled by deliberately flying below 100 radio + engines back at idle + a very late application of TOGA TL selection, that the prime reason for this crash was because Alpha Max was not achieved "instantaneously"?

What don't you understand here CONF ....?

Did he say that at a press conference or at the legal proceedings? There's no point going into a lengthy, technical explanation of the systems as described above if the audience has no technical expertise and will not understand it!

So, as rudderrudderrat suggests, you *are* actually arguing that an aircraft that is near maximum alpha for the current speed *and decelerating* will not stall if the elevators are subsequently deflected to the maximum? Rather you than me...

And as for your accusations of "complex, inefficient design", you couldn't be more wrong. For one thing, use of obsolete hardware meant that code efficiency was watched *very* closely and proven engineering principles were used to keep complexity down. The systems would be aware of deltas not just in airspeed and pitch, but also thrust setting and status. There simply wasn't enough airspeed to allow for more positive pitch and not enough thrust to power out of it until the aircraft was at the boundary of the forest - which was far too late. As people have pointed out before, Airbus invited pilots to pit their reflexes against the EFCS in simulated scenarios in the early days of the A320's life and to the best of my knowledge the protected aircraft outperformed even the most skilled pilot every time. Lest some pilots' hackles be raised at that assertion, this was not down to any particular genius on the part of the computers or software guys, but mainly by years and many thousands of flying hours put in by test pilots as performance data was gathered and the systems behaviour was refined.

It's not about embarrassment, it's about a bunch of disgruntled French pilots who can't let go of a two and a half-decade old issue no matter how many times they are reasonably proved wrong. If Airbus were truly trying to avoid embarrassment and deflect criticism, then why did they publicly acknowledge and correct a systems design issue - well ahead of the respective report -when one showed up after Bilbao?

Finally, I may not have direct access to the "lines of coding [sic]" - but I was taught by a guy who saw the end-to-end process first hand and could explain it thoroughly.

I should also make clear again that his visit in 1993 was not a jolly, organised by a grateful Airbus Industrie for a supporter, it was quite the opposite. Prof. Mellor was a well-known sceptic of civil digital FBW, and something of a constant thorn in their side - not just in specialist arenas such as the RISKS list, but also a prominent contributor to the highly-regarded "Black Box" TV series. While his report above concedes that he was pleasantly surprised by what he found, he retained a very cautious attitude several years later - when I first showed up in his lecture halls in 1997.

It certainly won't efficiently as the elevators are commanded nose-down as a start.
And if the elevators are commanded nose-down to arrest the pitch-up tendency from the engines, as submitted by dozy, it is even a poorer concept.
Remember, we are still 2.5 deg short of alpha max.

Instantaneous ?
It does not have to be, what matters is the intention, the intention to efficiently deliver.
The prime reason for the crash ?
Why would it be when the pilots put themselves in such a undesirable situation, but a contributory factor for the crash it has to be.

Conf iture
The aircraft was in high AOA protection mode which has priority over everything else. If the pilot was applying back stick why would the aircraft apply down elevators to prevent thrust pitch up?

I think it is time to review the principle and function modes of FBW C*.

Hi CONF iture,
Please have a look at Airbus A320 Fly By Wire Demo - YouTube from time 12:00. (link posted by alonso1986 in another thread)
There is an AoA gauge fitted and visible to the bottom left of the PFD.

During the demonstrated pull up manoeuvre, the AoA increases rapidly to 15 degs during the +ve delta g. During the steady 1 g climb, as the speed washes off, the AoA increases towards 15 degs again steadily over about 10 seconds. The AoA never exceeds its design limit (apparently 15 degs mentioned around time 10:00).

That is the sort of manoeuvre the system was designed for, and performs it very well.

Why?

The systems were doing as designed, and as refined by thousands of hours of flight testing by the best test pilots from across Europe. Not to mention that the system has been operating safely worldwide with a safety record that matches or exceeds older/more "conventional" types for over two and a half decades!

I've long been resigned to the fact that CONF iture will never let go of the idea that the aircraft coulda-woulda-shoulda cleared those trees if the nasty computers just let Asseline have those elevators up, but that opinion simply doesn't hold water against the known facts - the aircraft was decelerating, TOGA thrust from spooled-down high-bypass turbofans takes some time in coming, when it does come the aircraft will tend to pitch up (if corrective action is not applied) and above all that aircraft must attain stability before achieving full alpha max.

Based on the fact that the fudged approach was conducted in such a way that at least one step of the procedure was forgotten, that the altitude, thrust and speed stability were shot to pieces and the pilot actions once the danger was realised were poorly-co-ordinated and reactive, I have a tough time believing that the PF was in a suitable state of mind to take into account the thrust/pitch couple, the insufficient airspeed and the proximity to stall to "finesse" the controls in a superior manner to the EFCS.

Maybe the aircraft would not have immediately stalled if the elevators were actuated nose-up, but the resulting lack of stability if the aircraft exceeded alpha max or Vs1g would certainly have put the aircraft at a greater risk of no longer flying. I'd put money on the aircraft stalling with the combined pitch-up tendency of the thrust increase plus nose-up elevator in that scenario.

Perhaps a better way of looking at the way those systems work is not in terms of an implacable hunk of technology, but a system set up with the combined experience of top-notch test pilots to give the person in command of the aircraft a steadying hand if and when necessary.

@RRR,

thanks for the link to the A320 demo.

BTW the demo pilot was Gordon Corps, Airbus' chief (test) pilot at the time.

Something of an unsung hero, to say the very least. I'll say it again - I doubt very much that we'd still be having these misunderstandings and arguments had he not died so tragically and prematurely. I've had the pleasure of asking those who knew him about the way he worked, and they all agreed that on top of his professionalism and meticulous nature, he had an almost unique ability to explain and demonstrate things to both pilot and engineering audiences in a way that inspired confidence and respect from all. They also said that while his loss was tragic, his insistence on personally heading the safety team that went to the Himalayas to get to the bottom of the A300 accident was entirely in character. Did I say he's a hero of mine yet? :ok:

Worth clarifying that the second demonstration (12:00 or thereabouts) in the video is of a higher-altitude escape maneouvre and not a low-level flypast. My supposition is that the aircraft stabilises at around 15 degrees of AoA rather than the theoretical max of 17.5 degrees because there is a bank/turn component to the input, which was not the case at Habsheim.

Interestingly, in the first demonstration (approx. 9:50), Capt. Corps states that 15 degrees is the maximum permitted alpha in the landing configuration. Was AF296 in this configuration?