airtren

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.

DozyWannabe

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.

airtren

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.

DozyWannabe

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.

TTex600

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.

TTex600

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

Organfreak

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

Diagnostic

@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

airtren

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.

jcjeant

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

DozyWannabe

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.

lomapaseo

airtren

and your edit

agree

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.

Organfreak

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.

jcjeant

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

lomapaseo

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.

Pali

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.

BOAC

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

chrisN

BOAC, thanks. CN

Pali

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.

airtren

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.