Software bug fingered as cause of Aussie A330 plunge The final report into the 2008 Qantas flight QF72, which unexpectedly dived twice during a routine flight, has blamed a combination of software and hardware errors for the incident. On 7 October 2008, the Australian-owned A330-303 aircraft was cruising at 37,000 feet when the autopilot disengaged and the aircraft rose, before …
it's time for all the "Air France pilots were inadequately trained" people to come to the front about how the Airbus command and control system only fails when the pilots screw up...
and the rest of us can point fingers in derision.
Airbus: the best civilian aircraft the Consortium can force you to buy. It's BAE lite!
"it's time for all the "Air France pilots were inadequately trained" people...." An amazing display of ignorance and prejudice. The investigation showed that the Flight 447 flight computer was stymied by frozen speed sensors and so switched off the autopilot. It was then the inexperienced copilot that stalled the jet into the sea after taking manual control.
I think you'll find that most people here thought that it was combination of the two - AF447 was the victim of some rather silly decisions regarding the control of the plane, made worse by two loons that shouldn't have been let loose with a child's kite.
< < Appropriate icon for you, I think.
Seriously chaps, good work. Tell the machine who's boss. Humans have even higher redundancy than 3 built-in, but are slower. Sometimes it's advantageous. Additionally, good design that is both highly automated and allows manual overrides that make sense.
Also passengers: Keep your seatbelt on, if only for insurance claims - should you survive.
"It’s not clear what caused the ADIRU to shift into failure mode, as this is only the third time that it has happened in over 128 million hours of operation – although one of those other incidents was down to the same ADIRU in that aircraft."
Take that specific ADIRU out of the aircraft!!
If units fail that rarely, it may be in the best interest of both the passengers and the company to simply replace the unit with a new one.
If we start with the assumption that a repaired unit has the same integrity as a new unit, the chances of a unit failing twice is very slim. If it does fail twice, then statistically, either the unit is bad, or the computer reading it is bad (it may come down to bad shielding around that 'slot').
Since intermittent failures are nearly impossible to diagnose in some cases, I think it would be safer to replace the device altogether, rather than continue to fly with it. Intermittent faults are annoying when it involves an X-Box or a cell phone, but on an aircraft? Just junk it, and get a new one.
> If it does fail twice
If it fails, or is suspected of failing, just once then I'd be up for swapping that unit out for a new one. After all, it's a simple bolt-on box, it's not as if you would have to tear the plane apart to replace it.
Waiting for a unit to fail again amounts to gambling in my book. Someone in the supply chain was thinking "profit" before "danger" with that earlier decision.
The usual procedure for such failure is a return to the supplier, for extended analysis and tries to reproduce the problem. Don't forget that "software issues" will be applicable to ALL the equipment of the same model...
No one on the supply chain was thinking "profit", the unit was probably already returned, and the problem could not be reproduced - hence could not be fixed. It happens most of the time...
And as the price of such units is quite hefty (High dev costs and low volumes usually have this kind of effect), the decision to trash the unit is rarely an option. The worst cas for reluctant hardware is to end their life as "not for flight" bench bitch.
Two problems with just swapping the unit - firstly, you're not definately curing the problem; and secondly, the beancounters.
You are not curing the problem as you have not confirmed the unit is the definate cause of the problem. As mentioned, it could be shielding around the slot it plugs into, or an intermittant short or earth in the loom connecting the unit to the main system. To find the actual cause would involve a lot more testing of all the variables (like running the suspect unit in other slots to see if the problem moves with the unit or affects a "good" unit in the same slot).
Unfortunately, the beancounters are also not going to allow you to find the real cause. If you ask to remove the unit, the beancounters will simply say "no, it's expensive, if it passes diagnostics then slap it back in". If you ask for more time to find the real cause of the problem then the beancounters will point out the aircraft is needed to meet flight schedules. At the end of the day, we need more control for the authorities to step in and say that if an aircraft has a serious issue inflight, it is grounded until the definitive cause is found and fixed. If the definitive cause cannot be found, ALL possible items that could have been at fault have to be replaced (eg, AIRDUS, slot and loom).
I have been an avionics technician in the Air Force (US) and for a commercial airline. I have never ran into a condition where I couldn't R&R a black box for any reason other than that a replacement box wasn't available. Intermittent problems are a BITCH for a couple of reasons; one has already been mentioned, it might not be the box that is causing the problem; another is that when a box with an intermittent problem goes in for repair, the chances are very good that no trouble will be found with the box; firmware might be upgraded, mods might be applied, it will be tested, cleaned, and put back in stock. The biggest problem in cases like in this article, with intermittent problems that occur very rarely, you have no idea if the new box fixed the problem.
I hear all of the arguments about replacing this box, including "bean counters". However bean counters usually get persuaded by arguments involving loss of life and planes falling out of the sky - tends to be a bit more costly when that happens. I cannot imagine a bean counter saying no if his future depended upon making sure the airline was robustly protected against serious outages.
Connection issues: Really? Sounds pretty doubtful to me if the connectivity relies upon simple pressure fittings between components. I would expect every connection within and without the box to be clamped, with no margin for "iffy" connections.
With regard to swap-out, given the cost of these devices I would reasonably expect both the airline and the supplier to have worked out a support option on the contract which provides a hot-swap on demand. Presumably the original supply contract was for a few dozen units - and I would reasonably expect any competent supplier to add a few more to the quantity for build purposes.
And as for identifying which unit - a possible contender obviously, however under the circumstances I'd be up for swapping everything which could have played a part. As a hardware engineer (not with avionics) I have been in the situation where I swapped everything which could have been a cause. I never had a problem with a bean-counter declaring I had gone overboard, I was the on-site guy with responsibility for keeping the customer working and what I said was never questioned. Okay, most times I didn't swap everything, but it was always an option.
Just outside of Learmonth 6 km from Exemouth is a high powered VLF submarine communications station (Naval Communication Station Harold E. Holt). I've seen the aerial farm and it is huge. It is extremely interesting that the aircraft was flight over it at the time of the failure.
They stated that it didn't appear that any passengers were using any electronic equipment but you have to wonder about interference from the communication station.
This is not the first time this has happened over this area check out
http://en.wikipedia.org/wiki/Naval_Communication_Station_Harold_E._Holt
This post has been deleted by its author
You utter muppet.
I suggest you go and research the number of safety incidents with autopilot on vs those with autopilot off.
Then come back here and resume your meaningless pontificating if you dare.
You do realise how stastically insignificant this event was don't you but rather than strap the 60 morons in their seats you would rather endanger millions more by not trusting systems that are far less fallible than the meat puppets they replace.
You do realise yours is the same kind of ill informed opinion that make our politicians come up with dozens of knee jerk legislative and executive decisions every year right?
"I suggest you go and research the number of safety incidents with autopilot on vs those with autopilot off."
While, on average, the computer control is safer, you won't find the average human pilot aiming the plane at the ground and thinking its ok.
People say computer control in cars will make them safer as they can override human decision. What about the times where the human decision is the right one? Doing an emergency stop on a busy motorway wont be fun.
Out of which cavern have you come ? Please, when you do not know what you are talking about, please, shut up. The crash of the Air France flight over the Atlantic, aka AF447 was due to the pilots, not the aircraft - despite the fact that some equipment was not functionning 100%.
The aircraft stalled, was losing altitude, yet the pilots kept pulling the joystick iso pushing it to gain lift. The auto-pilot was not engaged during the time of the incident ... so yes, you are right, they were pulling the joystick and were going downwards ... all because they had no lift ... pilots were idiots like you, I guess !
"....While, on average, the computer control is safer, you won't find the average human pilot aiming the plane at the ground and thinking its ok....." Unfortunately, the investigation into the crash of Air France Flight 447 showed that unskilled pilots were too reliant on computer aids and were happy to fly their jet into the ground (or the sea in their case), despite other "manual" aids (like the stall warning horn) telling them different. The key to Flight 447's demise was ice-blocked speed sensors, which therefore gave incorrect readings to the computer. This caused the autopilot to disengage as the computer decided it couldn't trust itself, the more-experienced captain pilot was on a rest break, whereupon the inexperienced copilots stalled the jet into the sea. In the Quantas case it seems the passengers were lucky their captain was in charge at the time of the crissis.
Matt, basic airmanship is to ensure the plane will fly. Pointing the nose at the sky, even with full power is not the way to do this. By flying at sensible attitude with sensible power should ensure the plane flies. Watch the altitude and you can get an idea if you've got it about right with the rate of sink or rise. Now the 'pilot' never knew that the idiot 'flying' the plane had the stick back due to averaging feedback. Good design ? **NOT** ! The deep stall that resulted is easy to understand. The pilots never understood this until too late. I am truly puzzled as to why. Training issue ?
Now back to the original article, 2 out of 3 voting of inputs should have voted the faulty unit out. Either it was intermittent, or more worryingly to me, another device agreed within tolerances. Starting to prefer Boeing as they let the pilots have control when needed, and certainly the(nose high) stick position would be more obvious.
There is far more need for focus on training over the automation in each plane. Airbus have had their share of issues. The air france crash at the paris airshow in the late 80's was due to both pilot error (rushed unfamiliar manouvre) and the avionics (switching to landing mode without sufficient pilot warning).
Enough to say FAIL. Hope this encourages the whole industry to look at the cockpit automation issue. It is supposed to increase safety. I ask is it ?
"Doing an emergency stop on a busy motorway wont be fun."
This is only because arseholes drive too close to the car in front. If all cars were computer controlled, they wouldn't do that, and a car stopping in an emergency would alert the cars around it. Job's a good 'un.
I only say this because planes have exactly those kinds of system - automatic distance and collision warnings and computer-negotiated advice to the pilots on whether to ascend/descend/change underwear.
99% of the time the computer can fly the plane just dandy, but you should always have a meatsack ready in case something goes wrong. Duh.
It's a well-known fact amongst pilots that there are two seats in an airliner cockpit for a specific reason; one for the pilot, and the other for his dog. The pilot is there to feed the dog, and the dog is there to stop the pilot getting anywhere close to the controls!
Seriously, look it up.
AC, 'cos I may lose my right to free flights!
"While, on average, the computer control is safer, you won't find the average human pilot aiming the plane at the ground and thinking its ok."
Except they do:
http://en.wikipedia.org/wiki/Spatial_disorientation
http://en.wikipedia.org/wiki/Sensory_illusions_in_aviation
http://www.avmed.in/2011/04/spatial-disorientation-an-introduction/
The bottom line is that there is no single right answer; there are times when the computer control will malfunction, but so far those have been rather a lot less than those incidents where the human pilot has "malfunctioned".
While I do agree in principle with the Honorouble Anonymous Coward that:
"While, on average, the computer control is safer, you won't find the average human pilot aiming the plane at the ground and thinking its ok."
I also wish to point out that, statistically, you may find more instances of people in control of the aircraft who, for various reasons, or no reasons, have decided to point the nose of the aircraft, if not to the ground, then towards other impactable objects.
The problem is that the system is back-to-front. Far better to have the humans flying and the computers monitoring for errors than the other way around. Human nature being what it is, the pilots get to trust the automatics and lose valuable time in the rare event that something bad happens. With a lot of airline SOPs dictating that automatics should be used as much as possible, they also don't get practice at proper flying and, as was demonstrated by the Air France transcripts covered by El Reg recently, you end up with a pilot who actually can't fly the aircraft without help from the computers.
So basically - if I'm reading the report correctly - 1 of 3 inputs goes haywire intermittently ... but the software decision tree was expecting a hard fault, not a soft fault and when the device seemed to agree with the other two it but it back on-line only to have it go tits up again?
Averaging different inputs .... now where have we seen that recently?
Probably a human code bug - an unforeseen condition that the coders did not predict. My guess is that they will be burning some midnight oil with code reviews for a while now. Interestingly enough (after the industry accidentally killed a few people) when you write medical software, the first question asked is, "How can this kill someone?" ... reviews of flight code need to be, "How can this crash the plane?" ... not "How can we get the answer right?" - there's a big difference.
well... it IS the case, in theory.
The quite old DO-178b standard define 5 levels of dev process, from the "A" level (a failure may lead to a plane crash - Most of embedded software is rated at this level) to the "D" level (no real impact - Usually used for the maintenance software which is allowed to be used only in the hangar - And yes, the bootstrap preventing the use of such software in flight is A-level).
The "E" level is a bit special, as it refer to any non-DO software (quite rare actually. Even In Flight Entertainment softwares are classified as level C or D, as a failure of those will lead to additionnal work for the cabin crew : passengers are usually quite nervous when faced with a BSOD in a plane, i wonder why...)
Practically, due to budget constraint, the software activities are subcontracted by the "stamper" to the "best" (AKA lowest) bidder. The one with the cheap right-out-of-the-school graduate.
Me? I'm on this turf since 1999...
Good point - but as they say "In theory, there is no difference between theory and practice. But, in practice, there is."
In the end it's simply unrealistic to expect that any code will be perfect - which is why the pilots are there to give it the three fingered salute (just joking, for all you PPRuNe devotees).
Overall, flying is a hell of a lot safer these days than when I was a kid.
"Around 60 people were flying without their seatbelts fastened, despite being warned not to do so, and many were slightly or seriously injured after being thrown into the ceiling or side panels of the aircraft."
So of the 110 or so people injured, half of those were because some "free spirit" suddenly decided to occupy the same body space? Because they didn't want any restrictions on their freedom to move?
... but don't forget to add high-speed laptops, phones (in Flight Mode, of course), books, wine bottles, poorly stowed baggage ...
The list of serious injuries to those not properly secured is actually quite small.
(I don't understand the people that undo their belts as soon as the light goes off - it's an aluminium tube blasting through the sky at hundreds of miles an hour. What could possibly go wrong?)
It's an aluminium tube blasting through the sky at hundreds of miles an hour. What good would a loosely-adjusted lap belt possibly do.
I'd tend to suggest that thouse seatbelts are more there to stop panicky people jumping up and running around or provide some misguided reassurance, than any strong intrinsic safety properties. Three, four or five point harnesses for that job, methinks.
Airbus aircraft are too often brought down by software bugs (a.k.a. "pilot training" [sic]), with the aircraft structure being in perfect mechnical condition in the millisecond before impact. If they could "...Just....Pull-up...", then the aircraft would need nothing more than a software fix and the seats cleaned.
Boeing aircraft are often already heavily damaged on the way down. Even if they landed in a mile-high pile of peacock feathers, they'd still require major structural repairs.
Those that deny this observation about the too common distinction in the two major brands are doing a disservice to the safety of aircraft in general.
Yes, there are always exceptions. This is a 60/40 (or perhaps even 70/30) percentage thing.
It *is* way beyond statistically significant.
I don't recall the details and I'm too lazy to look it up, but I have read articles about the different philosophies embedded in the two companies' design rules. If I recall correctly, Boeing essentially trusts the pilots more than Airbus - the pilot is the final authority. He/she has the ability to override (some/all?) controls in ways that _might_ damage the aircraft, but also as a result has more ability to force the airplane to do what's necessary when the automated systems are screwing up. It supposedly goes back to Boeing's military heritage, where getting your own ass home might be more important than preventing the wings from being bent. (Many WWII fighter planes had a 'war emergency' power setting, which provided another boost of horsepower from the engines, but required an engine rebuild as soon as you got back to base.)
In summary, it's about who/what is the final authority - the pilot or the computer. I can't say definitively which is the best approach, but I'm inclined to go with the pilot most of the time - but this does demand that the pilot know enough to be trusted with that authority.
But, as I noted, I could have misremembered the whole thing.
What? like in the FADEC system installed in the Chinook which crashed on the Mull of Kintyre?
But the MoD said was "pilot error" (now disproved).
I DON'T THINK SO.
May the Lord preserve us from hairy-@rsed programmers, MoD "experts", poor maintenance and inadequate safety systems.
I don't think the actuator was designed by Boeing, I think they bought it in from somewhere else. I also remember only two write-offs and a major brown-trouser moment for the one that did manage to land safely despite two attempts by the rudder to take the quick way down.
You also have to look at how many service hours were trouble-free, which is what makes such failures so hard to diagnose. At least if something breaks, there's usually enough evidence to pinpoint the cause.
Quoting from 'pedias: Among them was the <B>Oh-My-God</B> particle observed on the evening of 15 October 1991 over Dugway Proving Ground, Utah. Its observation was a shock to astrophysicists, who estimated its energy to be approximately 3×10^20 eV (50 J) —in other words, a subatomic particle with kinetic energy equal to that of a baseball (5 ounces or 142 grams) traveling at about 100 kilometers per hour (60 mph).
more at <http://www.cosmic-ray.org/reading/flyseye.html#SEC10> but since this observation there have been another fifteen or so 'baseballs' observed. There's a vague possibility of dark-matter particles having a higher real-world momentum when they transit via terra.
It could have just been a proton with a very-close-to-light velocity.
Even in the LHC the protons have ~1 micro J energy. They wouldn't have to go much faster to reach 50 J. They would, of course, have had to have been accelerated by a mighty powerful mechanism but the universe is likely to have quite a few of those.
Cosmic Ray Incidents cause computers to fall over sometimes. Often for no other obvious reason. So if you've got a server down and the boss is pressurising for a full root cause analysis, but you've done as much as you can and have more important stuff to do, I recommend you pull CRI out of your hat and present it in the crash meeting.
It's a stunt I've been using for years now, ever since being made to spend many pointless hours tracking a fault on a Sun E10k. Sure: Others may laugh and scoff, but then you drop the Sun whitepaper in front of their noses, flick them a V, and bugger off for a coffee and a fag. It's golden, and sounds dead cool: "Yeah, we had a cosmic ray incident and it crashed the server out."
In short, in my many years of being a BoFH, THIS is the most important white paper I have ever read:
http://learningsolaris.com/docs/DRAM_errors.pdf
And here's a handy presentation to wow your line manager with:
http://www.ewh.ieee.org/r6/scv/rl/articles/ser-050323-talk-ref.pdf
I'm wondering if the Airbus guys just pulled the same trick!
Brilliant, isn't it? You might want to save those URLs for future reference.
who never pays attention to the safety briefing at the start of every flight. They tell you to keep your seatbelt fastened because it's good advice, as seen here -- and also because that way, when a pitch excursion throws you out of your seat and you crack your silly head open on a ceiling panel and then have to spend three hours getting an oxygen mask dislodged from your ear, they can avoid liability claims by the simple expedient of a sufficiently well-dressed "we told you so" -- which they did!
The general advice when flying is to keep your seatbelt loosely fastened - precisely for this reason. The pilot will even say this in his pre-amble, along the lines of "later I'll switch off the fasten-seatbelts sign so you can move around the aircraft, but we recommend keeping them loosely fastened for your safety and comfort".
Two reasons I do this personally. 1) unexpected turbulence is a b1tch on the best days, 2) when I'm sleeping after three bottles of wine, I don't want to be disturbed if they decide to switch the signs back on.
Personally I wear a seat belt at all times when I'm on an aircraft, except when I need to physically get out of the seat. I believe there are atmospheric conditions which can cause an aircraft to suddenly drop without warning.
Car seat belts must be worn at all times, so why not aircraft seat belts? Or is this another of those "green brigade" options where one's liberty is being threatened?
PAN is NOT a DISTRESS CALL
PAN is an URGENCY CALL
MAYDAY - the Distress Signal may only be sent if a SHIP or an AIRCRAFT is threatened by GRAVE and IMMINENT Danger. (Note : NO reference to injuries or people...)
PAN - the Urgency Call is used when the SAFETY of a ship, an aircraft or a person is concerned. (Note reference to person)
(International Radio Regulations Article 36)
You would object if some one called a router a hub; or a car a tractor and be upset if someone put petrol (fuel) in your diesel (fuel) powered car - and the difference between PAN and MAYDAY is way more impotent and has legal consequences and liabilities.
I hope they review the incorrect use of MAYDAY; after all aren't Pilots supposed to be able to fly and land manually ?
And quote
upgraded this to MAYDAY after seeing the seriousness of the injuries onboard
unquote
Sorry - the injuries have no bearing on changing the call. All medical problems remain PAN.
(my coat has the SOLAS regs; the ITU regs and the Radio Regs in various pockets; consequentially it's a bit heavy )
The plane WAS in GRAVE & IMMINENT danger.
It had lost all of it's main digital flight control systems, had flight control computers that the pilots couldn't trust, and had (likely - don't know if the report covers this) recently had two near-overspeed events.
Thus the pilots had no idea if the plane was still completely airworthy, as they couldn't trust any of the onboard computers.
Being over ocean, I would call that GRAVE & IMMINENT danger. Calling the MAYDAY immediately puts ATC on alert and puts ASR on alert as well.
I think he'll get away with MAYDAY - I wouldn't have trusted that plane as far as I could throw it.
The captain was well within his/her authority to declare an emergency through the use of a mayday call. Anytime an aircraft flight control system fails resulting in even a temporary loss of control the pilot in command must consider the consequences of a possible further degradation. Because the crew could not be certain that the uncommanded pitch was or was not the result of structural damage declaring an emergency was the right and proper action.
I don't know my PAN and MAYDAY regulations, so thanks for the heads-up on those.
However, PAN seems to suggest to me that the pilot is advising that he is coming in and would like a priority over landing if possible. Whereas MAYDAY suggests "I'm coming in with wheels down on my first approach, get everything else out of the way right now and give me landing rights over everything else".
Maybe that inference is wrong, but I always thought that MAYDAY would be the panic of last resort.
At the end of the day it's up to the pilot to determine his priority level for landing, and if he has passengers on board that are hurt and who may require hospitalisation then MAYDAY may have been the correct level.
Re PAN-PAN/MAYDAY
After the aircraft had plunged uncontrolled TWICE, I would have thought that the pilots could reasonably judge that the aircraft 'is threatened by GRAVE and IMMINENT Danger'.
The reason given for the MAYDAY following PAN may not be correct, but given the nature of the incident, MAYDAY was the right call, even if the reasons given were incorrect.
...although this report of the story states that they (quoting your quote) "upgraded this to MAYDAY after seeing the seriousness of the injuries onboard" that doesn't mean the same as "upgraded this to MAYDAY **because** of the seriousness of the injuries onboard" only that they upgraded to MAYDAY after seeing the injuries.
Although this story has that implication, they may actually have upgraded to MAYDAY because of any number of other reasons, including their (understandable) lack of understanding about what was happening with their aircraft.
It is, after all, their responsibility to get the craft down safely and if they want to call MAYDAY, well, frankly, they are the ones closest to the problem, and anyone here on the ground days weeks or months after the fact who points and jeers or snipes at them for it should take a chill pill and give a little understanding to them in that they felt the situation was that serious.
To quote from VHF Radio by the RYA:
"DEFINITION OF DISTRESS
The definition of distress in the 1979 Search and Rescue Convention is:
Grave and Imminent Danger to a Person, Ship, Aircraft or Other Vehicle Requiring Immediate Assistance.
DISTRESS is announced using the word MAYDAY ...
Emergencies that do not fall into the distress category but where an urgent message needs to be passed concerning the safety of a person, ship, aircraft or other vehicle, are URGENCY messages prefixed PAN-PAN."
According to my training (admittedly maritime not aviation) MAYDAY was exactly the right call once the nature of injuries were known.
Passengers for their injuries then make it compulsory to wear a seat belt at all times instead of making it advisory.
There is a history of computer problems with airbus, from the pilot not being able to overide the controls that would have prevented a crash (the computer knew better) to spurious flight controls and numerous glitches. Read up on the history of airbus crashed and the words over complexity come to mind.
May be they are trying to mitigate the compensation, the word AR*E comes to mind.
"The article clearly states the light was on."
It does? Where?
The article states:
"Around 60 people were flying without their seatbelts fastened, despite being warned not to do so,"
Being warned is not the same as saying the seatbelt light was on.
Also, as the aircraft was cruising at 37,000 feet, it's unlikely the seatbelt light was on before the incident occured.
who doesn't listen to the safety briefing! They tell you to keep your seatbelt fastened whenever you're in your seat, not just when the light goes on. The light is for people who don't ever pay attention to anything that doesn't light up and make noise at them, which is why it's saved for the parts of the flight where attitude excursions are likely, rather than any time they're possible -- otherwise, it'd be on constantly and people wouldn't pay it any mind at all.
...but flying around North and Central America, even at cruising altitude in clear skies, it is the exception to the rule that the seatbelt light is off. On most ~3 hour flights I've been on that light is off for less than 30 minutes.
Maybe it's just U.S. based carriers that do this... if it's a way to protect against insurance claims that would make sense.
Airbus crash at French airshow, crash in Austrian Mountains, crash Russia, Crash China, Crash Nepal.
Over complexity, and pilots attempting to avert disaster tried emergency maneuvers which the aircraft computers deemed outside the flight envelope and refused to allow. The aircraft would probably have survived the move.
An over ride system was then installed.
As to the pan call, I've used it once, it means 'this is bad but I'm not about to die yet'. Mayday means 'scrape what's left of me up'
Yes I had a significant fuel leak.
"The aircraft would __probably__ have survived the move."
Using the word 'probably' doesn't strengthen your argument. It's not exactly a ringing endorsement of what is 'true'.
If, as you say, "an over-ride system was then installed" doesn't that represent another layer of complexity? At what point does this become 'over complexity'?
Assuming the "French Airshow" crash you mention is Flight 296, that was pilot error.
I can find no reference whatsoever to an Airbus crash "in Australian Mountains"
I can find one reference to an Airbus crash in Russia, Flight 967. This was caused by pilot error, extreme stress, and an ill-trained pilot.
I can find no reference whatsoever to an Airbus crash "in China", although Flight 780 suffered a double engine failure on approach to Hong Kong
I can find two references to Airbus crashes in Nepal (Flight 331 and Flight 268). The first was caused by pilot disorientation, the second by the pilots very carefully guiding their plane in to the side of a mountain they didn't know was there.
Or, to put it another way: You're making it up.
> Assuming the "French Airshow" crash you mention is Flight 296, that was pilot error.
*Might have been* pilot error.
There was a documentary a few years back that showed some rather troubling allegations - e.g. one of the flight recorders was very old (on a brand-new aircraft), and that recorder had a *sudden* change of sync (by 7 whole seconds) compared to the other one just before the accident. The implication was that someone had dibbled with the recording to make it appear that the pilot had reacted too late.
The official transcript of the CVR had two bangs in it (the programme claimed that this was compressor stall leading to loss of power at a critical time), yet the released audio had no such noise...
Most troubling from my perspective was an interview with the CTO (IIRC) of Airbus, who claimed that the computers couldn't possibly have gone wrong, so it must have been a pilot error. That's arrogance of unimaginable proportions.
But it must be said, the pilot was attempting a low-speed, low-altitude, high-attitude fly-by in a large aircraft. He was doing that presumably because it's a comparatively difficult manoeuvre. The stunt went wrong. So it *might* have been pilot error, although IIRC Airbus Industrie were advised to make some changes to the pilot displays.
Vic.
Austria not Australia, and I think it may have been actually Germany they were landing at Strasbourg. There were several causes of the crash, one appeared to be that the pilots set the rate of decent as 33000 ft per second (displayed as 33) instead 3.3 degrees (displayed as 3.3) caused because the display in the cockpit was badly designed. There was also a problem with the air traffic directions, an airline cutting costs by not installing ground proximity radar. And real dozzie an interaction between a freak wind gust, pilot action and the autopilot.
The aircraft was flying at FL 370 or 37, 000 feet with Autopilot and Auto-thrust system engaged, when an Inertial Reference System fault occurred within the Number-1 Air Data Inertial Reference Unit (ADIRU 1), which resulted in the Autopilot automatically disconnecting. From this moment, the crew flew the aircraft manually to the end of the flight, except for a short duration of a few seconds, when the Autopilot was reengaged. However,
############ it is important to note that in fly by wire aircraft such as the Airbus, even when being flown with the Autopilot off, in normal operation, the aircrafts flight control computers will still command control surfaces to protect the aircraft from unsafe conditions such as a stall.##############
The faulty Air Data Inertial Reference Unit continued to feed erroneous and spike values for various aircraft parameters to the aircrafts Flight Control Primary Computers which led to several consequences including:
false stall and overspeed warnings
loss of attitude information on the Captain's Primary Flight Display
several Electronic Centralised Aircraft Monitoring system warnings.
About 2 minutes after the initial fault, ADIRU 1 generated very high, random and incorrect values for the aircrafts angle of attack.
These very high, random and incorrect values of the angle attack led to:
the flight control computers commanding a nose-down aircraft movement, which resulted in the aircraft pitching down to a maximum of about 8.5 degrees,
the triggering of a Flight Control Primary Computer pitch fault.
The actual issue is the arrogance that's been embedded into the design decisions leading to a user interface that thinks it knows better.
"...than the meat puppets they replace." Ah, that's a good example of exactly the sort of attitude I'm going on about. That attitude leads *directly* to this sort of (near) accident and many others exactly like it.
What the designers and their defenders don't seem to realize is that the "meat puppets" have eyes and common sense. Locking them out of the control system (as too frequently happens with Airbus) is a design FAIL. And that's exactly what happens when the computer systems go insane.
The Boeing user interface approach (generally with better feedback and allowing user overrides) is demonstrably better with respect to these sorts of accidents.
"Locking them out of the control system (as too frequently happens with Airbus) is a design FAIL. And that's exactly what happens when the computer systems go insane."
Where in the article does it say the pilots were "locked out" of the control system? The second paragraph states the autopilot disengaged twice, i.e. the plane was (unexpectedly) placed under manual control. The third paragraph describes how the pilots landed the aircraft using backup instruments and manually controlling systems that they couldn't trust the computers with.
American Airlines flight 587
"The National Transportation Safety Board (NTSB) concluded that the enormous stress on the rudder was due to the first officer's "unnecessary and excessive" rudder inputs, and not the wake turbulence caused by the 747. The NTSB further stated "if the first officer had stopped making additional inputs, the aircraft would have stabilized"
If you have triple redundancy on hardware and one of them goes down, taking 5 minutes to reboot isn't so bad. Either you loose it for 5 minutes attempting to rectify the situation and possibly regain normal operation of the kit, or you don't try rebooting it and just count it out for the rest of the flight.
Hell, while NASA was still flying the shuttle when one of the General-Purpose Computers crashed (rare but it has happened), one of the spares would be loaded with the software and take over and then the crew or ground control would shutdown and reboot the failed GPC, run some tests and put it back in service *
Satellites in orbit around earth or even interplanetary probes also get the odd reboot once in a while when the flight software glitches out, no problem! #
Software problems in well designed and critical embedded systems are rare but when they do occasionally fail usually all that is needed is a power-cycle.
* http://www.aviationweek.com/aw/blogs/space/index.jsp?plckController=Blog&plckBlogPage=BlogViewPost&newspaperUserId=04ce340e-4b63-4d23-9695-d49ab661f385&plckPostId=Blog%3a04ce340e-4b63-4d23-9695-d49ab661f385Post%3a6a907fc4-90b7-4e3c-9536-5b8acee9d152&plckScript=blogScript&plckElementId=blogDest
# http://www.theregister.co.uk/2011/01/04/galaxy_15/
Why is the flight control software allowed to make a decision to nose-dive without acknowledgement from the crew? Shouldn't that be an out-of-bounds parameter?
I also still don't understand why, in regards to AF447, Airbus' software doesn't sound the low altitude warning until 2000ft mid-flight.
Are the crew made aware that the ADIRU unit has entered failure mode?
Surely the 2 functioning ADIRU units could call on the fourth (ie THE PILOT) in that situation?
Surely the aircraft should be providing all data to the crew at all times and in exceptional circumstances where a decision is made that falls outwith normal flight parameters, wait for authority from the crew before suddenly nose-diving for example?
I do appreciate that this must be hugely complex, but it somehow strikes me as obvious that autopilots shouldn't be able to execute certain manoeuvres without confirmation from the manualpilot.
@b166er, when you say "Why is the flight control software allowed to make a decision to nose-dive without acknowledgement from the crew? Shouldn't that be an out-of-bounds parameter?" you fail to understand what the article said.
The auto-pilot had disengaged, the flight control software wasn't doing much at all.
...in regards to AF447, Airbus' software doesn't sound the low altitude warning until 2000ft mid-flight."
I'm not an aircraft engineer (just a sim pilot) but as I understand it, the GPWS* is coupled to the radar altimeter, which points down and slightly forwards, and is used to give altitude *above ground level*.
Since it only really works up to about 2000-2500ft AGL, that would be your answer.
The main altimeter clearly works all the way up to the aircraft's service ceiling, but it does so based on air pressure, and reports altitude *above mean sea level* - it has no way of "knowing" where the actual ground is.
For reference, I usually fly the POSky 757-200 and -200C, so it's not an Airbus-specific thing.
*The box that shouts "TOO LOW - TERRAIN!" at you. It also gives altitude callouts on descent.
No errors in 128 million hours..Sound awfully like the proud statements they made before installing HAL...and we all know how that worked out.
Seriously though - I very much doubt any testing was done for this scenario. You can only test for what you know, not for what you don't. At least the backup routine worked!
Call me an untrained outsider but if a machine I'm operating (or riding in) decides to do things it was neither asked nor programmed to do then this is an emergency. In this case until that plane was stationary on the ground with its engines shut off it it presented a danger to its passenger & crew and anyone in its way.
I design embedded software. Even though I like to think that my software is pretty good I won't trust it in any situation where it could threaten life or property. That requires completely redundant -- and different -- systems, not this "best of three" stuff. I don't trust a lot of coding techniques; what's OK for a desktop application just won't cut it in a machine, the code has to be designed with failure in mind, not as some 'exceptional' event. (Although I'd hope that Airbus's contractors know what they're doing they are obviously making assumptions about what can and cannot happen during the operation of their kit and they're discovering the hard way that you just can't do this -- any input, no matter how unlikely or meaningless, has to be assumed to be valid until proven otherwise and coped with accordingly.)
Looks like a similar problem to Air France's mishap - computers confused, so they ask the meatbags for assistance.
Luckily, Qantas actually TRAIN their pilots for this kind of event, and they did exactly the right thing: ignore the computers, go manual, land ASAP.
Injuries to passengers, well, you are a goose if you don't keep your seatbelt on! Think - you're travelling at +800kph - even a mild bump will slam you into the nearest wall or ceiling if you are not restrained.
I've been on planes that have hit bad turbulence, and that have had to make landing aborts due to wind shear - despite their size, airliners can be flung around pretty hard when they need to be or the weather gets nasty.
Good on the QF pilots though - and THIS is why they deserve their pay.... and why Qantas shouldn't contract out to cheaper overseas pilots. Especially French ones!
"......Especially French ones!" Making sweeping judgements based on comapring between incidents of a different nature is not a good practice. In defence of the Fwench, it looks like the Quantas crew had their experienced captain in charge at the time of the problem, or had time to get him into the seat to take charge. In the case of Flight 447, the captain was not in the cockpit and had no chance of getting to it before the inexperienced copilot had stalled the jet into the sea. I cannot comment on the relevant experience levels of the Quantas vs AF copilots, and it is unlikely that, in this time of budget cuts, airlines will be putting three expensive senior aircrew in every cockpit when they can get away with one captain and two relative trainees.
"the captain was not in the cockpit and had no chance of getting to it before the inexperienced copilot had stalled the jet into the sea"
Personally I find it concerning that the copilot would be so inexperienced they would not be able to control the plane without the computer, surely thats part of the regular tests they do!
They were likely referring to the normal suggestion that passengers should keep their seat belts fastened whenever possible. ... which is good advice in any case. It is more common for unexpected turbulence to cause passengers to gaily bounce around the cabin. The old trick of leaving the seat belt very loose, but attached, would of worked here (with perhaps some minor bruising).
Look folks, I'm *far* from the first to make these observations about how Airbus aircraft occasionally actively participate in their own destruction. There are some almost unbelievable examples of self-destructive behavior by Airbus aircraft listed in the applicable section of the following.
http://www.opednews.com/articles/From-the-Comet-and-Airbus-by-William-John-Cox-090612-829.html
There are many similar factually-supported commentaries. Google is your friend. The more you pay attention to the incident causes, the more obvious the pattern becomes.
That's a truly dreadful article. On the one hand it's complaining that Fly-By-Wire means the pilot can't feel when it's over-stressing the aircraft, and on the other complaining that the pilot can't over-stress the aircraft. It then gives an example of a Boeing plane being manually operated beyond it's control limits, saving the plane whilst causing damage, and then mentioning that the Airbus FBW software doesn't allow that. But the Boeing plane was under *manual* control at the time, and the Boeing software puts *exactly the same* limits on pilot input. An Airbus plane under those circumstances - under manual control - permits *exactly the same thing*. It's a nonsense example. Apples and Oranges.
I note at the bottom of that page that "William John Cox authored the Policy Manual of the Los Angeles Police Department". Clearly an expert in avionics then... </sarcasm>
R. A. Heinlein always had three computers navigating his space ships in his sf stories.
Maybe three is not enough; maybe we need another that will continually ask the others if they are feeling OK? are they depressed? what exactly are you doing with that packet from Skynet?
Probably get told "Well, Clippy, I am presently flying us into the side of a hill so you will shut up!"
Am I the only one to find that a revolting description that betrays a dismissive attitude to the abilities or people?
Perhaps contributors need to review their attitudes to their fellows and even to other animals and then design and test their systems with a moer aware mindset.
Seems this is a bit like the classic, "nothing wrong with the system until you let users near it".
No matter what, the point is that the *ware (hard+soft) got coerced into doing a sudden dive. Twice.
Now, i'm not really into planes software, but common sense says that when all your input fails and/or goes inconsistent, you DON'T change "state". You go with last set of "sane input" you had before things went to hell.
These people do have a budget to test their systems with fuzzed data and watch how it behaves, right? We not talking the toaster industry here, where the worse that can happen is burnt bread...
Beer, cause that was about as much "testing budget" as i could get for many softs i wrote...
This post has been deleted by its author
The failed component was made with pride in the USA, by a company that also supplies Boeing. I'd bet the same boxes are in service in Boeing craft too.
Leaving jingoism out of it, the safety records of both makers are comparable. If I wanted to assess safety, I'd be looking more at the maintenance procedures used by the airline than who originally assembled the fuselage, tbh...
there are dozens of airlines that are not allowed to fly into US or European Airspace simply because the maintenance procedures are not up to scratch.
South East Asia & Africa Im looking at you. Cough **Indonesia** Cough.
There are also many examples of good Aircraft operated by Bad Airlines being grounded the minute they touchdown in European Airspace.
There was a famous story of a plane that spent 2-3 years parked at Dublin airport because the cowboys who operated it could not raise the funds to rectify the many problems with it.
..."- even a mild bump will slam you into the nearest wall or ceiling"
Your failure to understand Newtons Laws. The First Law means doesn't matter how fast you are travelling (at constant velocity and therefore acceleration zero) - stationary or 800kph makes no difference - there is no force.
Its the rate of change of velocity (acceleration) which affects the size of the force (Second Law).
It was the acceleration due to the 'sudden' drop which caused the impact injuries - that was factor here, not the 'static' speed.
Funny story regarding Brit trials of a computer system to control artillery firing nuke shells. The boffins did all the code, ran the tests with a prototype, it all worked fine. Before handing it over to the Army, they got the office secretary to transpose thier scribblings into a proper document. The secretary was using her brand new word processor and let it run a spellcheck, happilly substituting all occurences of "lattitude" and "attitude" with "altitude", the latter being the only word of the three in the spellchecker's dictionary. The result was the first run with a production system, loaded with code from the doc, was a (thankfully inert) shell fired into the ground only a few hundred yards in front of the gun!
@yeahyeahno
'While the aircraft was in cruise at 37,000 ft, one of the aircraft's three air data inertial reference units (ADIRUs) started outputting intermittent, incorrect values (spikes) on all flight parameters to other aircraft systems. Two minutes later, in response to spikes in angle of attack (AOA) data, the aircraft's flight control primary computers (FCPCs) commanded the aircraft to pitch down'
Say again?!
Those spikes should been (if not plainly ignored) offered to the flight crew for sanity checking and the FCFCs should not be able to respond to spiking data, plain and simple. Surely, a spike by definition is an out-of-bounds parameter, analogous to the pilot accidentally knocking the stick!
So let me get this right, you want any spikes in data input referred to the flight crew for sanitising, by the time the alert has popped up on the display it'd be too late.
Obviously the spikes should be ignored, which is why there are three Inertial Reference Units (IRU), if one of them disagrees with the other two it gets ignored. What seems to have happened here is that the frequency of spikes from the bad IRU was such that it confused the rejection routine allowing them to get through which then drove the autopilot to compensate for something that wasn't happening. Taking manual control should get around this problem as although the spikes may be reflected in the flight director display the pilots wouldn't follow them even if they could. Imagine the speedo in your car cutting out for a fraction of a second randomly every few minutes, cruise control would go mad but a driver may not even notice.
It seems to me that the flight crew updated the PAN to a MAYDAY because they couldn't figure out what was wrong with the flight computers and decided to stop trusting them and land the aircraft manually, as soon as possible.
In any case, having one or two pax injured is a medical problem; having over 100 and lots of your cabin crew injured becomes a safety problem IMO.
Part of the problem is the arrogant (you can guess who I'm referring to) Blame-The-Meat-Sacks attitude and the continual denials.
I would have though that the 'Paris Airshow Landing In The Forest Just Beyond The Runway' would have tempered the arrogance; apparently not. 'Thick face' (opposite of hunble) is the term for the reaction. I would have though that the 'Chinese Pilot Applying 400lbs-f to the Please Go F-ing Up Handle' (and the idiot airplane ignoring it and insisting on landing in the sea) would have made the trend clear. How about the Russian case where *ONE* of the three autopilot channels essentially *silently* disengaged? I've lost track of how many ErrorBuses have insisted on landing (crashing) in places other than the nearest runway. I've lost track of how many have flipped over in flight because of some trivial instrument or sensor problem.
The Airbus User Interface is mentioned in MANY incident and accident reports. Non-Airbus user interfaces are simply better.
If you deny this, then you're part of the problem...
You see all these downvotes you're getting for each and every one of your posts on this subject? I'm sure you think it's because we're all "pro-Airbus" on your imaginary "pro-Airbus or pro-Boeing" false dichotomy. It's not. It really isn't.
It's because you're boring, repetitive and wrong.
Thanks Mako, I'm learning things! But isn't GPS accurate to about 50ft, can't that be used with digital terrain elevation data to determine at least a reasonable estimate of altitude relative to the ground? (it seems that amonsgt all the other redundant systems, we're missing one for altitude calculation which is surely THE most important piece of data to a flight)
@SkippyBing, only where such spikes would result in severe deviation from accepted norms.
I still don't understand why that spiking data wasn't out-voted during the rejection routine, but I guess Airbus will go to work on that.
I'll go out on a limb here and face the flames if I'm due them, but when you say the computer wouldn't know about the spikes until after they happened, surely there could be some short lag between incoming data and outgoing executions? Does an aircraft need to react the millisecond data is compiled from the sensors?
Sorry for going on, but I find this fascinating and, well, while there are minds about to question :D
'Does an aircraft need to react the millisecond data is compiled from the sensors?'
Actually yes, that's why they use computers rather than allowing humans direct control.
Basically it's down to how stable the aircraft is, the more stable it is the greater the drag which is obviously bad for fuel economy. Something like a Cessna, or an old airliner like a 707, is very stable and will return to its original attitude without input from the pilot which means you can use direct mechanical controls and manually trim the aircraft to hold the right attitude.
Because modern airlines are run to ever tightening margins there's continual demand for greater fuel efficiency, i.e. less drag, which is achieved by making the aircraft less stable (not unstable, just less*). However this makes the aircraft more sensitive to the point where a human pilot wouldn't be able to react in time to correct things. I don't know if airliners are on the edge of controllability however they're definitely at the point where it would be very tiring for a human to keep up. And the one area were autopilots definitely win is in fuel economy, Ryan Air apparently get all kinds of shirty if the pilots turn it off.
Re the spikes, without knowing how big they are it's hard to say whether they should have been excluded automatically. It wasn't that long ago that an airliner lost its rudder because the forces on it were twice that expected so it'd be presumptuous to assume we've got all the forces on an aircraft figured out in all conditions.
Incidentally on the altitude calculation part, it's actually not that important most of the time, because when you're cruising >10000' above the top of Everest ground proximity isn't really an issue. Most GPWS do have a terrain database, but in the Air France case that wouldn't have helped because they were over the sea and there already would have been an alarm to indicate they were below the desired cruising level. There're only so many alarms you can put in something to tell the operator he's being an idiot before it becomes counter productive, which I think they discovered at Three Mile Island.
*Fighters on the other hand are in to the negatively stable area which is a whole other can of worms.
It could have been a 'soft error' where there is a glitch under very specific conditions. I had this happen when deisgning equipment to evacuate airports where a subtract instruction didn't set the negative flag when executed at one memory location!
Still, the data from the faulty system shouldn't have prevented data from the other two being processed correctly, I would put that down as a design flaw.
Just like FredScummer said earlier, it's best to keep your belt on whenever the aircraft's wheels are not touching the ground (and even a bit longer). He's right there are atmospheric conditions that even the auto-pilot can't handle (and auto-pilot's are better at handling turbulence than pilots but only when they work properly).
"Software (and hardware) bug(s) fingered as cause of Aussie A330 plunge"
Double plunge actually. Software bug. Citation? See headline.
User Interface (a.k.a. human factors) means things like: The trim wheels *not moving* as the computer slowly and silently adjusts the trim to compensate for things slowly and silently going all pear shape. The pilots will be made aware at the last second when the trim reaches the stops. Boeing aircraft make the trim wheels move so that the pilots at least have a chance of noticing the slowly spinning trim wheels.
User Interface means things like aborting the landing when the pilot pulls back on the stick. Early Airbus would continue to land (in the ocean) even with the pilot pulling for all he's worth.
There's about a dozen or more major differences in the design concepts.
These are very bad design decisions. Some have been fixed over the years, others not.
Typically I don't use a headline from an IT website as a thorough Air Incident Investigation, that's just me though, you use it for evidence.
Considering most of the 'user interface' as you call it is governed by CS25 and whatever the FAA equivalent is then it's not really down to Airbus or Boeing how things work or even what colour the displays are.
Incidentally, User Interface does not mean Human Factors, that's something completely different in aviation. Have you tried google?
For arguments sake, assuming all these claims of Airbus design issues from you are true, why does the American FAA certify Airbus craft as airworthy?
According to you, there is enough evidence to not allow Airbus craft into American airspace. "Fundamental design flaws" All those Boeing lobbyists would be having a field day with all this "evidence". Boeing, as an American company. can bankroll an American election campaign as well, Airbus can't.
You also are not explaining why Boeing has the same overall safety (and failure) record. Either your evidence is false, or Boeing have other "fundamental design flaws", that at the end of the day make the failure probability the same.
Making "Boeing/Airbus" irrelevant in the big picture.
This issue was clearly not related to any possible human interaction design philosphy difference between airbus and Boeing.
There was a fault in an ADIRU which generated erroneous data periodically. The FCPC was designed to use data from 3 ADIRUs to ensure it was using valid data but the specific pattern of erroneous data was not detected resulting in erroneous data being used. The failure mode of the ADIRU was not identified by the manufacturer of the ADIRU in its failure/hazard analysis and is still not understood.
If there is any blame to airbus it is in the algorithms used to handle and check the 3 sets of ADIRU data. This is not described but it sounds like there is an assumption that faulty ADIRU data will be persistently faulty. This is nothing to do with human interaction design.
"While, on average, the computer control is safer, you won't find the average human pilot aiming the plane at the ground and thinking its ok."
The autopilot thought the plane had somehow gone into a stall and therefore pointed the nose at the ground to try to gain airspeed to get out of the stall. This is the normal way to get out of a stall. The other way is to crash, CF what happened to AF447 where the one thing they didn't do was point the nose at the bloody ground and pick up some airspeed, thereby stalling into the sea. Arguably if they'd switched the autopilot back on (on AF447) the crash wouldn't have happened.
To repeat the point made elsewhere - there have been far more incidences of people flying planes into the ground than of autopilots doing it.
As for the 737 comment - they upped the landing speed to 150 kts and that seemed to do the trick. It's one of the reasons 737 landings tend to be pretty hard and fast.
Think about Air France 447 and its mysterious and still-unexplained disaster. Perhaps another "bug" that had a less-fortunate outcome.
System failures of all sorts are inevitable, especially as systems grow more complex and lend themselves to failure cascades induced by unanticipated chaotic interactions.
Of course, if you were bent on destruction, you might find even ways of exploiting those bugs.
My newest thriller, Die By Wire (diebywire.com) revolves around a man who buys a reliability testing company that services airliner computer systems. His aim: even if you can't eliminate all the bugs (like the Aussie A330's) you can exploit bugs that you do detect.
I'm a book author now, but have been the CTO of a tech start-up, worked with computer systems for 40 years and know a couple of things about systems failure. One of the reasons I wrote the book was to bring wider attention to the issues of fly-by-wire failures.
The pilots responded to their instrumentation. But the computer generated instrumentation was at odds from how the aircraft was actually behaving ... and given the rough weather, trusting instruments would not ordinarily be a bad thing. They responded appropriately in relation to instrumentation, but not appropriately for reality. That's a different matter than simple pilot error.
I'm not sure it's that simple. Yes, the flight data recorder indicated the pilot at the wheel climbed the aircraft into a second stall that ultimately doomed the aircraft. But if you look at the context of the final minutes, it is quite possible that the instrumentation was in conflict with itself, giving erroneous information that was impossible to resolve correctly.
This is one of the best narratives available an contains some solid expert context: http://www.popularmechanics.com/technology/aviation/crashes/what-really-happened-aboard-air-france-447-6611877
Yes, it is startlingly obvious that pilot error can be disastrous. And that is usually what airlines and manufacturers would always like the public to think. That quickly absolves them from blame.
But I do not think that this can be dismissed as simple pilot error.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
