Originally Posted by
TTex600
However, I want to understand the technology.
Excellent - I'll help if I can (and thanks for the previous post).
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.
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.
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.
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.