Organfreak,

I appreciate your recent posts, and your "green" note.

I find it hilarious that DozyW*e replied on this note, as this type of questioning/accusation is on his resume on this forum... which I've taken as a device in his tactical arsenal, in pursuing his self assumed mission of public opinion control regarding AF447.

Well dang, heaven forbid I make it clear that I wouldn't stoop to giving people grief via PMs, given our disagreement up until that point. For what it's worth, I was PM'ed by the same person some time ago stating that you and Lyman (then bearfoil) were the same person. If this turns out to be false then you have my apology.

You've got me too here for a moment....

I was referring in general to an airplane involved in an accident - you've "quoted" the last part of it - but I agree the wording could be clearer in that respect, so I edited, to make it clearer.

If you have a problem with it in its edited form, please let me know.

You show me a post where I said the aircraft and systems were perfect. At the risk of sounding juvenile, I bet you can't.

Not at all, I've stated outright that I don't think it's as big a deal as some are making it out to be, and I'll give you some reasons if you like:

• More than 30 UAS incidents in the A330/340 passed without incident. If not being able to see/feel the other pilot's sidestick was a safety concern, more of them would have crashed.
• At least two aircraft equipped with interconnected yokes had a similar LOC/stall/crash event, one of which shows evidence that the F/O didn't like what the Captain was doing and did not overrule him.
• The sidestick design was approved by one of the most respected test pilots and safety gurus of his day.

Well, when one has been here 9 years and has seen the same people make the same arguments over and over again, it's difficult to resist noticing and commenting on the pattern.

I hope I've answered your questions, so as such I see no systems weakness in the design other than the pitot tubes. Perhaps you'd be kind enough to give me the benefit of your opinion on the matter.

Thanks, my FCOM/AOM shows ADIRU input into the ISIS, but I'll take your word that it derives it's own attitude and airdata information.

Be that as it may, my point is still unchanged. Everything on the panel is computer generated. The only thing I can count on in the Airbus is the horizon out the windscreen.

If I was scared of the technology, I'd never go to work or I would change employers and go back to flying a DC9. However, I want to understand the technology.

On a related subject, I have been in a 319 that failed to respond to SS input asking for nose down. I was maneuvering, avoiding one buildup and flew into another which was a substantial updraft. I had already pitched for green dot trying to climb above the first buildup and when I flew into the second updraft the aircraft failed to respond to my nose down, fwd, SS input for a couple of seconds. I assumed at the time that the updraft caused a "g" loading that fooled the ELAC. The buildup was small and we flew out of it in a few short seconds. PM me if you have any input.

FWIW, Dozy once sent me a PM and was quite the gentlemen.

Thanks, airtren. Though it's obvious that I cannot fly (with or without an airplane), I assume that I'm getting a bit of respect here because I can think clearly and can easily understand the issues raised. /ego trumpeting

Just for the record, your honours, I didn't accuse Doozy of sending me the creepy PMs, nor would I, chiefly because they were from a different registered member here, who, oddly, has never seen fit to post in these AF threads, that I can remember.

Anywho, back to one of the matters at hand. DW, you posted, among millions of other things,

With all due respect, you're still missing the fine distinction that is being made here. These "fine gurus" forgot to anticipate one big possibility, namely, the eventuality that the PF might not know what the hell he's doing.
That may be the difference in why those 37 other UAS ABs did not crash.

Those of us who harp on this are not trying to destroy Airbus; it is rather an intellectual curiosity that wishes to understand ALL of the "whys" involved, not just one big, simple black-and-white picture.

I had better subside before I write myself into a "deep stall."

@DozyWannabe:

While I appreciate your posts and I learn from your comments, I cannot let the following go without commenting:

I respectfully suggest that saying "without incident" is an over-simplification, which may be unhelpful in diverting attention away from the (IMHO very relevant) information about what happened on previous UAS incidents where enough info was gathered for BEA investigation.

Check Interim report 2, PDF page 51 onwards, and you'll see these points. Note that only 13 UAS incidents had sufficient data available for the BEA to do a sensible review of them. Sure, none of the other flights crashed, but several were not handled according to the QRH, not all of them went into Alt* law meaning that subsequent actions cannot sensibly be compared to AF447, etc. etc.

My view is that where the detailed data is available to allow a reasonable analysis, there were systemic issues in UAS handling shown in that data for several other flights (e.g. failing to recognise that UAS had occcurred, not correctly disconnecting the FD, incorrectly re-connecting the AP during the UAS event etc. etc.). In other words, some holes in the swiss cheese did line-up in other UAS incidents, but just not all of the holes as on AF447.

The evidence is clear in that section of Interim report 2, that (in the 13 events where sensible analysis could be done) incorrect & potentially dangerous handling of some other UAS events has occurred. IMHO, that is not consistent with the statement of "without incident", unless you mean "without crashing", which is not a great measurement :)

Due to the points above, the actual sample size of comparable UAS incidents is so small that, given the (thankfully) low rate of crashes anyway, I believe the sample size is too small to support your assertion regarding whether more of them "would have crashed" or not. I'm not asking you to agree with me :)

This caught my attention, as it seems related to the points made during the discussion on the #6 thread, about the THS versus elevators during the AF447 stall.

Hi,

DW
And this is the biggest weakness you can found on the modern planes who are using computers and automated flight systems
This is one of the most important source of data for the automation system
Another failure of testing and certification process .... and so another invite to disaster
For a Curtiss Jenny .. a pitot tube clogged was not a very important problem ... for a Airbus or other brand using automation .. it's a crucial data loss

Excellent - I'll help if I can (and thanks for the previous post).

OK, so why do you feel that to be the case?

For starters, I'll identify myself as a software engineer (which is a fancy way of saying computer programmer trained in traditional engineering discipline). I've said a lot of this before, but in this case I'll try to summarise as briefly as I can. Please forgive me if I'm going too much back to basics - the last thing I want to do is sound like I'm teaching people to suck eggs.

In general, the computer systems that make their way into aircraft are a world away from the way that they have been portrayed in popular culture over the years, and from the systems you and I use to post on this board, for example. The analogy I like to use is that modern home computers are like a highly-tuned racing engine, and the computers in your aircraft are more akin to an old pick-up truck engine, or possibly a marine diesel or something. Breaking that analogy down, home computers are designed with the latest technology in the hardware, and software that is designed to maximise use of the hardware available (with all the complexity that implies). It is therefore accepted that a breakdown or crash is expected to happen relatively frequently and also that the system itself will be replaced on a relatively short timescale. Industrial and embedded systems (including the realtime systems used in aircraft) use obsolete and trusted hardware (the processors in the A320 were obsolete even by 1988 standards), and the software testing process and inbuilt redundancy is several orders of magnitude more involved than in any other discipline. It is also designed to be very simple in design - almost comically so to a programmer - where real-time systems stop being funny is the level of smarts required to build machines that can perform complex tasks using only these simple, exhaustively tested sets of instructions. It is specifically designed to run for years, if not decades without incurring a fault - and if that wasn't enough, there's an implementation of the same specification running on the other computer with entirely different code, and the two implementations are constantly checked against each other.

The upshot of which was that in order to certify the A320 and her sisters, the engineers had to prove that each component and program involved was as reliable, if not more so, than the steam-gauge equivalent. If you think about it practically, the millions of flights performed by FBW Airbuses since their introduction - without a single serious incident attributed to the flight control software - is nothing short of remarkable if you haven't been drilled on just how strict the development process was, and still pretty impressive even if you have.

[EDIT : One of the reasons I dislike the "HAL" analogy is because HAL was a fictitious construct to allow a storyteller to advance his plot - if I were to use Captain Sullivan from "The High And The Mighty" to characterise pilots, I would be quite rightly chastised. It's better to think of the A320 systems as a whole bunch of "HAL"s that are constantly checking each other, are capable of shutting down a "HAL" who is malfunctioning (and, importantly, take over his functions until they land), and if the active "HAL"s can't work it out, Dave gets to do whatever he needs to get them home safe. ]

Going down even further, it's worth noting that the ADIRU units themselves are nothing more than translation units. They get a simple set of inputs in from the air data and inertial sensors and translate them into a format that is used by the flight control computers and the EFIS. All the EFIS does is render that information into a visual display - nothing more, nothing less. It can't change the values, it does no summing or checking of the values (that's done by the flight control computers, which check the values against each other). In short, all the data path from the sensors through the ADIRUs to the EFIS does is mimic the old-fashioned mechanical or electro-mechanical data path used in the steam gauges. Involve the FDs and things get a little more complicated, as the flight computers get to input to the EFIS as well, but one can't change the other.

Basically, if you've got a good set of inputs from the sensors, then there's no reason to think that what you're seeing on the EFIS is not the 100% unvarnished truth. The system is also designed to degrade gracefully so that, for example, if the pitot tubes are blocked, you will lose only airspeed information - all the rest of it should remain in place. A situation like this is "abnormal" in the sense of the system as a whole only - in terms of the individual components this has been designed for and the system is designed and programmed to compensate. This is significantly different from home computers where an error in one task can have a detrimental effect on the others.

I hope that helps and if you've got any questions please feel free to ask.

If the updraft was strong enough to significantly alter the "G" loading then the ELAC was not "fooled", as such - it was doing what it was supposed to. In such circumstances you've got two options - either give the sidestick a little more down-pitch to counter the G-loading from the updraft or (probably more sensible, as you did) ride it out until the updraft passes. You clearly knew enough about the aircraft and how it works to work that out.

That said, if I recall correctly the system should allow for maneouvres up to 2.5G (just shy of the structural limit of the aircraft when sustained), so I suspect there was a little more to it than that - as to what that "little more" was, your guess is as good as mine. :)

@Organfreak - just to reassure you, I wasn't accusing you of anything. I just wanted to make sure people knew that I wasn't harassing you outside of the thread, given that we've been crossing swords recently.

@Diagnostic - I was, perhaps incorrectly, using "without incident" as a euphemism for "not crashing". You're also right on the other point - my stats and engineering professors would kill me for using such a small data sample to make my case, but unfortunately it's all we've got.

@jcjeant - Losing one pitot tube should no longer be a problem for modern airliners. What we had in this case (which hopefully by now has been remedied) was a situation where they were routinely losing *all three*. That this could happen with a design that nevertheless passed certification requirements is extremely worrying, but that's a different subject.

airtren

and your edit

agree:ok:

regardless of who's at fault, he who breaks the crockery must pick up the pieces

That's the basis of continued airworthiness

in other words no manufacturer or operator is going to allow his product to continue to injure people, just because they feel it's the other guys fault.

The issue for some time has been, what has been done, what will be done and when,

I'm just not impressed with pages and pages of discussion about the future actions needed from folks that have no dog in this arena.

I have no dog or cat in that rodeo, but I might have my a** in your Airbus!

(So, it matters to everyone who is curious.)

Rethpecthfully Thubmitted,
Etc., etc., ret.

Hi,

DW
Technically seem's nothing is changed ..
No new certifications or new tests
I think it's only some changes .. paper work and some supplementary training
Pitot tubes keep their weakness .. and pilots must leave with it
No good
The work must be adapted to the workers and not the contrary (Taylor rule)
BTW .. it was many incidents with the Pitot tubes .. and all know that incidents are always the precursor of accidents (it's always a precursor and if no "crackstopper" is put in place for stop the failure .. you have the accident)
Concord had 57 incidents with tires ... (precursor) and in the fatal accident .. the tire was involved
Nothing mysterious

Organfreak

Curiousity is one thing, but telling the experts how to do it or that their fix won't work is quite another

When it comes to managing safety on an existing product, one does not go back to the original design and tinker with that as it will take far more time to wring it all out since you will have likely introduced new unknowns.

You are more likely to get far faster results by tinkering with minimization and redundancy and upgraded manuals and training.

Sorry folks for being interrupted by a frequent passenger, but regardless of this endless argument, is there any lesson for pro pilots from this tragedy and discussions? Is there any agreement between pilots on what to do with more care and skill to prevent such a horrible scenario? Is there anything what changed minds of pilots since CVR and FDR of AF447 have been found?
Thank you.

- PNF by my reading of the report. (PS Liked the comments in brackets:))

Pali - as I said many moons ago on another of these threads, I hope so. I hope the lesson that we still need basic flying skills gets home to those who need it and that those who fly Airbus - or any other fly-by-wire aircraft - realise that 'flying' it might one day not be a simple 'walk in the park' and that it can kill you and your passengers just like any other piece of flying metal.

BOAC, thanks. CN

Pali - as I said many moons ago on another of these threads, I hope so. I hope the lesson that we still need basic flying skills gets home to those who need it and that those who fly Airbus - or any other fly-by-wire aircraft - realise that 'flying' it might one day not be a simple 'walk in the park' and that it can kill you and your passengers just like any other piece of flying metal.

Thank you, I hope with you. :ok:

Software engineer is quite generic nowadays, doesn't tell much. It's like saying I am a pilot. Without more info... doesn't say much. The type of programming, or software, the programming languages, and depending on that, the processors one has programmed for, would be more descriptive...
I will make some additions, and a different analogy - I don't know what "highly-tuned racing engine" or "home computer" you had in mind, as I particularly don't think that a "highly-tuned racing engine" fits the home computer reality.

A.
Using motor vehicles for the analogy, I would say a home computer is rather like a small size sedan, you can use it at many basic things around the home for the family. Depending on how recent it is, it may have a few more horse power than a previous instance of the model, and a bit more room in the trunk, or more comfortable seats.

The car has many generic components that are used in an entire family of cars.

The central piece that make the home computer usable, is the operating system - the OS - which is a very special set of software programs which brings usability to the hardware. The programs of this set are completely different from the general software used on the computer. Some of these software programs, and their modules, are extremely specialized for one or a few tasks. A very critical subset of modules is grouped into what may be called "kernel", or "core", which is always active on the home computer, and any problems with it result in a crash of the entire computer, requiring a complete reboot. The operating system is separated from the rest of the software through sort of a "virtual fence", to ensure the unaltered functionality, reliability, and security. The OS on a home computer is of a "general use OS" category. The rest of the software on the computer is applications software, and is more general in nature, in terms of how the software is written, and computer resources they have access to. Applications interact with the OS through an interface, called Application Programming Interface (abbreviated API), which allows a controlled passing through the "virtual fence". In general, each application software may provide certain specific functions, or functionality to the users. There may be several applications that provide the same functions, for instance, one may have several Internet browsers, or several text processing applications installed on a home computer - for instance Notepad, Wordpad, and MS Word. The separation, or the "virtual fence" between the operating system and applications allow installing new applications, or new versions of existing applications, or removing applications without affecting the operating system, or the other applications. Furthermore, the malfunction of one application is different than the malfunction of the OS. While the malfunction of the OS can result in a computer crash, affecting the entire computer, the malfunction of an application results in an application crash, which affects only that application and immediate use at the time of its malfunction, and does NOT affect the rest of the computer (rest of applications and OS). After such an application crash, one can just restart, or activate again the application. Each application has a user interface, which allows a direct interaction with the user. An application may process different data, depending on its type, and the user's needs. For instance a Spread Sheet program may process financial data for a user, or the small shop inventory for another user. The "user interface" of the application is using OS functions - through the API - for accessing specific hardware components tasked for interfacing with the user, like keyboard, mouse (input), and screen (output). The application may use the OS "file system" functions - through the API - for storing or retrieving data from a 'hard disk", "external disk", or "memory card", a "CD", or "DVD". Furthermore, the application may use the OS "data networking functions" - through the API - for interacting over the data network - Internet - with other applications - for instance a browser would be in this category. Some applications are present but run seldom, or not run at all.

B.
The computers used in a modern a/c are more like a very specialized very rugged type of vehicle used by some police/fire/rescue departments for intervention in very special and adverse conditions, for instance mountain trail conditions. They could not be used for a family's daily errands, or for going to a pic-nic, or vacation. The extreme reliability requirements translate into the use of components that are well known, well understood, verified by time, use, and abuse, but also manufactured for functioning at different specs than the generic ones - for instance temperature, pressure, humidity, radio interference, etc... .

The software running on these computers is in the "real-time", or "critical response-time" category, while it is also in the "dedicated" category, as opposed to "general use". The operating system is very specialized, and performs only a few tasks that are necessary for the functions of that computer. It can be regarded as a small subset of a home computer operating system. As response time is critical, the software is supposed to be highly efficient, and therefore is written following very specific requirements in terms of using the computer resources, or processor mechanisms - this makes sure that time consuming ways of using/programming the processor are excluded. It is likely that the computer would have only one or a few application programs installed. An application provides a very specific function, or small set of functions. It starts when the computer is turned ON, and runs permanently, as long as the computer is ON. It does not have a user interface, it always accepts as input, processes, and provides as output the same type of data. The line of separation between the operating system and applications is totally blurred or not existent - installing a new version of the the application if ever it is done by installing one new block of software, which contains the OS. A malfunction of the application is unacceptable, but if happens, it brings the entire computer down. A computer crash is in general "unacceptable".

Lastly, the algorithms that the application is programmed to perform are designed and specified in general separately from the software. The software application is only a materialization of the algorithm. Therefore a bug or a malfunction in the software is completely different than, and should not be confused with a bug or malfunction of the algorithm.

This protects against "software bugs/problems", but NOT against "algorithm bugs/problems". An algorithm "bug" is materialized in both implementations, and unfortunately is railing each of the two implementations into the same "bogus" behavior.

So how many "algorithm bugs" (aka logical errors) do you see manifesting in this accident? Because I still don't see any.

And it was quite possible for an application to take out other applications on home and business OSes until very recently (until Windows NT4/2000 and MacOS X to be precise), because the previous generation did not have adequate "siloing" of running tasks.

We're getting *way* off-topic here though - it was an analogy, not an exhaustive description - and your version lacks the main point I was trying to make, which is that real-time systems in aircraft are not "centralised" around an OS in the same way home and business computers are.

On #1, "Diagnostic" has pointed out well and sufficiently the issues with it.
How many more casualties are necessary? to consider everything that may be a weak point important, or a “big deal”?
On #2, You're simply making my point about the SS location and virtual secrecy problem, and that of the "yoke" supporters, which is that the F/O saw quickly and understood well what was wrong. Why he didn't intervene is a completely different matter.
On #3, So what? I recall that others on this Forum refuted this point a while back, and you still think it is a "reason". Furthermore, you should know this if you have the expertise you've advertised: the approval of a tester cannot make a product, which is tested within certain limits, bug free!!!

To conclude, these are non-reasons, i.e. zero (0) value, relative to the AF447 case...

You should here what system architects from various industries say, about the "lack of visibility/virtual secrecy" of the A330 cockpit, and how this becomes an example of a typical bad choice for the control center of a critical mission system.
So, you had your self assumed badge for about 9 years? I've joined in July 2011, and your ""anti-Airbus brigade" defense badge" is outshining anything else that I could notice of similar nature.

As, I said before, I think you should reflect on this: do you really think Airbus needs this type of help?

14 -15 years is "recent"? There are people that made a profession from looking for holes in the "virtual fence" between OS and applications to use that to do damage, and others to close, or fix these holes, and prevent such damage.

It's very far from an exhaustive description. Among other things, I think I've made that difference clear, between a Home Computer OS and applications, and a A/C's real-time computer OS, and application, which is why I wrote it.

They won't. So far no one has come with solid reason why they should. Perhaps I'm mistaken, but I don't think that powers that be consider statements preceeded by "I think", "I feel", "I find" and "I believe, made on anonymous forums worthy of their attention. Those who really believe they can contribute to improvement of certification standards should better send their signed opinions to relevant authorities instead of airing them on PPRuNe and similar fora.

Given current level of technology, it wasn't and it couldn't be designed to protect from stall when having no realistic airspeed measurement. Of course, if you have idea how to overcome it, I would be delighted to hear it.

They had aural indication of excessive AoA.

So you realize the aeroplane was stalled. Do you realize, that when stalled all bets regarding controls authority are off except that it should be sufficient to unstall the aeroplane if appropriate control inputs are applied timely? Alternatively, if such criteria can not be met, aeroplane has to be equipped with automatic stall prevention device, colloquially known as pusher. Aeroplane was pitching down even with full nose-up elevator, when power was reduced so there is no need for precise pitching moment diagrams to see that connecting AF 447 with horror stories of irrecoverable stalls and swept wing pitch-ups is not red but infrared herring.

If it is true, then both of you are unaware of lag associated with hydraulic powered controls.

So far there's no indication that any instrument on board of AF447 failed. ADRs correctly measured pressure in total line. That it wasn't total pressure is not instrument failure but probe clogging.

It's manageable. Same way it was on JN. Attitude + power.

I'm certain it's just me but I couldn't find reference to the occurrence mentioned in interim3, could you please direct me?

Might be that airworthiness requirements got relaxed but on older Airbi it's not ADIRU signal input, it's shared pressure lines on stby instruments and ADR3. For pilots & maintenance folks it is of utmost importance to be able to tell the difference between the two.

This is a very serious occurrence, sir. Could you please provide relevant NTSB reference (or local investigating entity's one, if it was international operation).


Not a single flight where analysis was possible was handled IAW procedure. Atmosphere doesn't care if you use QRH as crutch, as long as you keep the AoA in the band that assures that the aeroplane keeps flying.

Yup. One out of 37 did not. Thirty-six out of thirty-seven went into alternate law. Some got stall warning. So pushed. Not pulled.

Eh?

No. I'm just suggesting that technical analysis clearly shows that most of the AF447 puzzle solution is in HF domain.


1. Their paperwork has shown no anomalies so in the eyes of the law, they were.

2. Once upon a time there was a certain senior training captain who was smiling from the airline advertisements. Once he made a beginner's mistake of taking off without clearance. So died. Took 582 people with him. Do we call him non-pilot for that?

What does that even mean? You're starting to sound like bearfoil again.

How much?

That the industry has a bad habit of "regulating by counting tombstones" is an uncomfortable truth, butthe point I was trying to make was that in the vast majority of those cases, the Airbus flight deck layout was more than enough to effect a recovery and arrive at their destination in one piece even if, as Diagnostic says, mistakes were made in the initial handling. That says to me that the design works at leas tas well as any alternative as far as the mission as a whole is concerned.

You'll be surprised to note that I disagree emphatically. If you compare the CVRs. both the Birgenair F/O and the AF447 PNF were well aware that the aircraft was not being handled correctly, but instead of taking control, kept making suggestions to the handling pilot. In the case of AF447, it would appear that the PNF was waiting for the Captain's approval to take control from the PF, and in the case of Birgenair the PF making a hash of it *was* the Captain.

No-one ever said it was bug-free, it simply passes the certification requirements on reliability that the non-digital predecessors of the instrumentation had to pass. I don't recall being "refuted" either, so if you'd care to furnish me with an example, I'll catch up.

What systems architects? Show me. I can cast-iron guarantee you that you'll find just as many - if not more - who say the system is fine. You keep using the phrase "virtual secrecy", and I do not think it means what you think it means.

Blow me down if I'm not being judged on 9 years of contributions based on 4 months of an occasionally heated discussion on one incident - and you accuse *me* of extrapolation!

In any case, the people I'm talking about materialised around 2004 and they blanketed any Airbus related thread with links to the website of one Norbert Jacquet, and later Henri Cornus - both former Air France Captains-turned-internet cranks who blame Airbus for the loss of their jobs and prestige. Some melted away over time, some are still around.

I'm not trying to help Airbus, I'm trying to get to the bottom of the issues behind the accident, and rehashing 20-year-old arguments about computers in the cockpit, yokes and feedback are getting in the way of that. The reason most of the more esteemd members of this board gave up on this subject months ago is because it always comes back to the same old same old. I only bother because I don't want to see Jacquet- and Cornus-sourced misinformation reprinted in the national press, whose journalists clearly know no better.

I'm not going to be CONF's monkey, and I'm certainly not going to be yours.

And, lest we forget, his fellow countrymen and pilots so categorically refused to believe that their premier pilot could make such an elementary mistake that they tried to blame the controllers (based on their assertion that they heard a word that sounded a bit like "futbol" on the ATC tape, which none of the other investigators heard), and the crew of the other aircraft involved (based on the fact that they did not turn off at the C3 exit, which was a practically impossible turn for a jumbo to execute, and elected to use C4 instead). To this day, the Dutch report still makes these assertions.

- bottom of P90

HUH???
 

Excuse me, but I fail to see how your response (to my comment to DW!) has anything to do with my simple suggestion that perhaps the authorities will reconsider what they certified, since I suggested nothing to them, nor would I. Only a complete fool would believe they could influence the authorities from here. You're changing what I said into something else! I really don't get where you're coming from. :confused:

Having once again learned something new here, in the future to avoid lag, I will plan on making all flight control inputs before I'm aware I need them.

Clandestino typed:
What does that mean??? Wind noise??? FAs falling base over apex???

So now what? you now realize what it means, and you're taking it back?

You went from saying that "design" and "software" are not perfect, to "systems" and "aircraft" are not perfect, and when I make a note of the progression, and progress, you're asking me what it means?

How does that sound? I would say just like yourself.

Have you reflected, thought, been aware what it means when you said what you've said?
.....

Can you clarify your statement of the Airbus "design" problem with the pitot tubes, per my earlier request?

Or is just a throw in the air, as you know well that the "pitot tubes" are already "done deal", and there is nothing to loose, or gain, by saying what you're saying?
You're answering with a question? You've mentioning betting, its yours, you want someone else to give your words their worth?

If there is anything wrong with the industry counting the tomb stones as an indication when there is time to get serious, is that it waited way too long, not that it takes actions, when there are fatalities.

You're clearly wrong, as based on your badge, you're not willing to admit that an airplane full of passenger casualties didn't happen earlier by pure luck, or science of statistics, and that there is a very simple and obvious factor in the cockpit that made it more difficult to isolate immediately the mistakes and correct them, as to prevent the loss of 228 lives, a factor that is recognized by other airline manufacturers, and by other industries.

No, the PNF had a suspicion, a guess, a hunch, but never knew, couldn't know for sure, with 100% confidence, which is why he could not tell the Captain, when the Captain rejoined the cockpit what's going on, why, and how things got there.

We have the PF's SS actions on the FDR traces, and we are in such a comfortable spot to be able to say what is wrong with those SS actions, as the traces clearly tell us.

But you're not willing to admit, that one of the reasons the Captain failed until the end, like the PNF, to see exactly what those actions were, is what is so obvious to many - the lack of visual contact, the lack of ability to see the positioning of the stick, and the actions on the SS, which yes, is "a virtual secrecy" created for the direct PF actions on the SS, for those that are in the cockpit.

You would be your monkey, as your input queue is yours, and the responsibility to manage it properly is yours.
Really?

Per your own posts, you're trying hard to influence and control this Forum, as to guide it into the belief that the only problem with the airplane is the problem known well before the accident - the pitot tubes - and that the ample data provided by this accident show no problem with it.

You would have to do a lot to change the credibility perception for statements like the one I just made.

I have no idea what was the discussion or problems pointed out were years ago. I looked at the AF 447, case and data, with no dog on the track, and what's obvious is there obvious. The fact that similar discussions existed before, is just an indication that the problem existed from day one.

lag, instruments and AoA one mo' time
 

Salute!

- As mentioned, there can be lag in control surface position versus control stick/yoke/wheel position and rate of application ( hereafter referred to as "stick").

"lag" can be implemented to get a better handling jet or to keep you from ripping the wings off, and it can be modified by pure mechanical doofers in the actuators, feedback of surface forces in the actuator, or firmware/software.

For example, observe the Viper or Typhoon at your next airshow ( two FBW jets). Note how quickly the jet stops rolling. Lag? Yep. The roll command implements a lag filter when rolling into a bank, and a reduced lag filter when relaxing the stick. So simply relaxing pressure, or deflection of the stick, gets you back to the trimmed roll command or "protected" bank angle that the 'bus has in some laws.

- We must distinguish between "instruments", displays and sensors. Granted, the actual pneumatic sensors on the 'bus may have accurately measured AND displayed the poor data, but many folks call that "instrument failure". The AF crew even calls out " we have no indications". So what does that mean? Is it the sensor or the actual display?

With known unreliable speed at the outset of the story, when did the system ( input device, sensor, display) become reliable again? Is the pneumatic vertical velocity valid? Is an inertial vertical velocity display available to use as a crosscheck? Hmmm....

- AoA, one more time.

Why ignore the AoA sensor inputs for stall prevention/ stall indications/displays? Is the 60 knot speed doofer a poor design implementation versus a simple weight-on-wheels "switch"?

Speed ain't a good thing to use for a stall indication. You can stall at almost any speed in many planes ( high performance jets usually cannot stall when flying at the speed of stink, heh heh, as you hit structural limits before AoA limits). You stall because you exceeded some AoA.

You don't need a full time AoA indication. In the Viper, we only had an AoA "bracket" in the HUD when gear was down, and used it for best approach speed. Lots more accurate than a "speed" we got using our gross weight and configuration. Easier, too, for we single-seat types. Ask 'bird, Retired, Smilin', et al. The U.S. Navy jets had a full time AoA display called an "indexer" that told you to lower the nose or raise the nose. The A-7, F-4 and F-18 of my era when the Earth was still cooling, but aerodynamic principles were well-established, had a full time AoA indication in the HUD.

Stick and/or rudder pedal shakers are neat, as are aural warnings. But we saw the AF crew seemingly ignore the aural indication. Not much re-design effort/testing required to add a "vibrator" to the stick. But would it be valid?

"we have no indications"........
++++++++++++++++++++++++
I always wonder why the new airliners don't have a HUD.

After all, they have only been around since the late 60's.

A HUD is invaluable when landing in poor weather, and it ain't too shabby for basic climb, cruise, descent. Using inertial data for a flight path doofer ( FPM), it's an excellent thing for crosscheck with the steam gauges or cosmic flatscreen displays such as the 'bus and others utilize. Seeing the FPM caged at the bottom of the HUD is a great indication that you are descending, regardless of your pneumatic system displays. Then there's the pitch lines to show the actual angle your jet is flying and pitch attitude if you have a body reference symbol ( like your basic attitude indicator). Sheesh, that HUD will spoil your crosscheck in a hurry, and it takes lottsa discipline to include the steam gauges.

Lastly, I do not go with the yoke/wheel crowd. For some, the visual or tactile feedback might help. But mostly you see what's happening on the displays or outside the windshield and ask the other guy what he's doing if you don't understand what's happening. BTW, I am not a true dinosaur, I evolved into a bird.

Hi,

Clandestino
Pilot handling was not exactly my point ...
For the JN when Pitot tube clogged you loss airspeed indication (visual) and no more
For the Airbus when pitot tubes clogged you loss airspeed indication (visual) and also a important data needed for the automation system .. and that is the most important point (design of the automation system)

Methink .. such incident will not show in any investigating entity's unless pilot made a report to airline .. and this airline send it to investigating branch office
I think (by what I read about reports and experience backup) that this event no deserve to be in a investigating entity archive
I can be wrong ... if it's the case the OP will certainly correct me in his answer

This particular day and time .. yes .. he was no more a pilot .. he forget he was a pilot .. and he was just a man trying to return as soon as possible at home

OK465
:) :ok:

Thanks, I missed that :ok: Seems that someone at BEA messed up by providing ADR switching traces twice, instead of ADR and IR switching. They have time to fix it in final. As there were no IR failures or disagreements recorded, seems that switching of RH IR source from IR2 to IR3 wouldn't make a difference to displayed attitude.

Did just that this summer at Zeltweg. Couldn't help but notice that both of them are combat airplanes, implying that they're on the opposite side of stability/maneuverability spectrum compared to passenger transports. If maneuverability is primary design concern, it's easy to reduce control lag by installing powerful hydraulic actuator. If not - weaker one will do just fine, it will be lighter, will strain hydro system less and require less beefing up of the structure it is attached to. That's why AF447 elevator traces shows gradual reduction from full nose down when forward stick was applied and not instant stop-to-stop wham.

Stall prevention - with pitot clogged there is no way for ADC to discern whether AoA or airspeed is faulty so it proclaims itself unreliable. With all three ADRs out, to reduce the risk of wrong protection kicking in, air data based protections shut off and leave the problem for intelligent beings to solve. That's basically what is meant by very technical term "Flight control laws"

Stall indications - it wasn't ignored. It worked properly.

Displays - no legal requirement for AoA displays to be fitted. With thousands of airliners flying safely every day without them and dozens of crews solving UAS just by reference to attitude and power, I don't find the logic behind not requiring AoA gauge in cockpit faulty.

Not quite. Since you have to introduce ADR input into stall warning system to cope with Mach effect on critical AoA, having 60kt cutout is actually simpler than adding WoW input and with it another possible failure point.


Thanks for the info. On PC-9 indexer comes alive only when gear is lowered, I assumed it is just for landing on every military airplane.

I am afraid that we get new equipment only if it makes economical sense to someone in charge. I have Head-up Guidance System in my Q400 because it was cheaper to graft IRS and HGS on her to make her CAT3A capable than to develop autotorque and autoland-capable autopilot.

Not to mention your landings will become more precise and softer with the help of the little birdie and then one day you'll be all f-ed up when your HGS gets MELed and it's back to switching between head down and up on landing again.

Why? Pilot handling is exactly what put AF447 into trouble.

It would be important if A330 is impossible to fly without automatics. Well, it was designed to fly with computers and sensors badly shot up. It's not heuristics but many thousands of hours spent on carefully designing and testing the plane.

Reading the description, it could be either hitting the low G protection at -1G and that makes absolute hell of cabin even with everyone strapped in or serious failure of flight controls system. Where I live either option is heavy incident, will leave massive traces on QAR that would be picked up by the FDM so non-reporting would result in tea without biscuits and it has to be investigated by government appointed investigation commission.

Since you say so, is this applicable to the case we're discussing, too?

Diagnostic
I am a private person and I value my privacy very much. That is why you will not see any information about my flying experience on my private page. It is also why I have not checked up on yours or anyone else's. I take everyone by what they write and that means the occasional mistake that they may post. But just this once I will make an exception - I received my instrument rating back in 1985.
I joined this board to learn about this particular incident but what I am learning disturbs me greatly. This doesn't seem to be about aircraft but about cultures of neglect and arrogance that develop in the professional piloting world and that scares me. We have Pan Am back in the 1970s, Korean Airlines in the 1980s, Air France now. The implications are very disturbing - almost as if there is a disease that can infect any airline. Arguments about automation and greater computing taking away flying skills may have some bearing but not really. Pan Am's culture happened in the yoke/mechanical linkage era. So did Korean's. There are thousands of Aibuses flying around the world - probably at least 50 of them are in the air as I write. All of them using sidesticks. There are thousands of Boeings - they use yokes don't they? Both input methods are equally valid and both have their adherents. However, the yoke would not have saved the aircraft in this incident because the issue is cultural not mechanical.

For the record, and despite I doubt it would have changed the outcome in the light of the crew actions, I see two of them:
1/ the non-inhibition of the nose-up autotrim when stall warning is active
2/ the inhibition of the stall warning under 60kt IAS (even if I understand the logic behind the inhibition, I still think it may be worth reworking that bit of logic)

And perhaps a 3rd and 4th, but as I don't know the logic behind I'm not qualified to fully comment:
3/ the V/S switching source from air data to inertial (and back); it occured in AF447 and its consequence was a non-readable/unreliable/unrealistic displayed (air data sourced) V/S, while at the same time a reliable/realistic V/S value (aka inertial sourced V/S) was available (for the system).
4/ the non-inhibition of the F/Ds (by the system) when an UAS situation is detected: why? A/P & A/THR may (and have) been dropped, why not the F/Ds as they may give unreliable directions in such a situation?


Nonetheless, I still fully agree with Clandestino here (my bold):
-----------

Yes I agree. And because of data missing, when tubes get clogged you have reversions in various systems.
But what do you make of that statement? Are you advocating that, because "automation" (which part(s) ? flight controls? A/P? A/THR? all of those? more?) uses air data, and air data is not 100% reliable, the industry should renounce "automation"??
I'm sure I must have misunderstood your point. Would you be kind enough to elaborate?

-----------

Now, on a more general topic, is it possible going back to the ball, i.e. leaving the players alone? :rolleyes:

[Regarding aural indication of excessive AOA]

I would think it's fairly obvious he means the a/c shouting "stall" at them continuously for almost a minute - but then it seems it wasn't obvious to those there on the night...

Where I differ from Clandestino and others is that I am not sure the binary on/off stick shaker or stall warning is an adequate subsititue for an AOA gauge once you've managed to get yourself stalled. Shaker / warning won't tell you any different between "you're nearly stalled", "you're stalling", "you're well stalled" and "you're more stalled than any test pilot ever went...".

Maybe the warning should get louder, shout different things, shake stick harder... or maybe it should be a cue to look at the instrument that tells you exactly how far you are from flying.

That said, I have a suspicion it would have made little difference on 447 - the AOA would quickly have been pegged at max (25) and then disbelieved.

At least! Just now, 221 FBW/SS equipped Airbii are broadcasting (ADS-B) in zones covered by private receipters of the FlightRadar24 network (which is most implanted on Europe, and it's night over it at present). And to compare: 293 B7xx at the same time.

/off topic

So, you've echoed repeatedly publicly an idiotic statement sent to you via a PM - I have no idea who the "same person" you're mentioning is - and offer a conditional apology?

The Moderator deleted your first post, after you refused to do it at my respectful request, but then you keep repeating it, as soon as I start posting, as a tool of intimidation.

You need to do a lot better than this post.

You can start with your own computer expertise - as an advertised software engineer, you should do a lot better - as you seem to have no clue on detecting network applications impersonations, continue with your interaction with the Moderator, continue with a better management of your tactical arsenal devices and finally improving your apology section.

Here is a post on the topic, which tangentially points out the 3 different Stall states, and possibility to have an error message for each.

http://www.pprune.org/tech-log/45687...ml#post6598193