Toronto Escorts

Software bug in 777 causes Malaysia Airlines jet to go nuts

l69norm

Member
Jan 25, 2004
707
0
16
I found the original article. This is part 1........

http://online.wsj.com/article/SB114895279859065931.html
http://64.226.131.145/discus/messages/1/2822.html?1149018014

The Wall Street Journal

Incidents Prompt New Scrutiny Of Airplane Software Glitches

As Programs Grow Complex, Bugs Are Hard to Detect; A Jet's Roller-Coaster Ride

Teaching Pilots to Get Control

By DANIEL MICHAELS and ANDY PASZTOR
May 30, 2006; Page A1

As a Malaysia Airlines jetliner cruised from Perth, Australia, to Kuala Lumpur, Malaysia, one evening last August, it suddenly took on a mind of its own and zoomed 3,000 feet upward.

The captain disconnected the autopilot and pointed the Boeing 777's nose down to avoid stalling, but was jerked into a steep dive. He throttled back sharply on both engines, trying to slow the plane. Instead, the jet raced into another climb. The crew eventually regained control and manually flew their 177 passengers safely back to Australia.

Investigators quickly discovered the reason for the plane's roller-coaster ride 38,000 feet above the Indian Ocean. A defective software program had provided incorrect data about the aircraft's speed and acceleration, confusing flight computers. The computers had also failed, at first, to respond to the pilot's commands. Within weeks Boeing Co. warned airlines world-wide to install a fix provided by Honeywell International Inc., which makes the flight computers and supplied the faulty software.

Such glitches, while extremely rare, are emerging as a top safety challenge in the air. With well over five million lines of code used on the latest jetliners, versus fewer than a million on older planes, it's increasingly difficult to detect and fix embedded problems before they surprise pilots.

Plane makers are accustomed to testing metals and plastics under almost every conceivable kind of extreme stress, while software used on commercial aircraft is prepared and checked much more rigorously than applications developed for everyday uses. But it's impossible to run a big computer program through every scenario to detect the bugs that invariably crop up. And in airplanes, such vulnerability to undiscovered errors can lead to consequences far more dire than an email outage or spreadsheet error.

Now officials have begun re-examining flight data from past accidents and incidents, searching for ways in which bugs might have contributed to slip-ups or led to other problems. "It's our next big area of work," says Peggy Gilligan, a top safety official at the Federal Aviation Administration in Washington. She says industry and government experts recently "came to the realization that we haven't looked at this area" closely enough. Regulators also are studying how to improve detection of wayward software and train pilots better to handle crises involving computer breakdowns.

Serious software bugs such as those aboard Malaysia Airlines Flight 124 haven't been blamed for any major commercial jet crash. Advances in electronics are a big reason air travel has become safer. But several incidents -- including one that caused a Virgin Atlantic plane to make an emergency landing in Amsterdam last year -- are ringing alarm bells.

"A total loss of flight control could be worse than a fire on board," says Robin McCall, a veteran Delta Air Lines captain who flew highly automated Boeing 767s before retiring last year.

Capt. McCall says automation failures can make it tough for pilots to revert to basic flight procedures and work around the problem. The Malaysia Airlines drama, he says, is "among the scariest scenarios in all of modern aviation, since the plane was out of control" for some 45 seconds, despite the crew's efforts.

Malaysia Airlines and Honeywell declined to comment on the incident because it remains under investigation. Its details are discussed in reports by Australia's aviation authority. Scott Pelton, Boeing's chief engineer for electronic systems, says the incident was "clearly unacceptable" and prompted swift remedial action.

In theory, most advanced jetliners can take off, climb, navigate along a prescribed route, descend to their destination and roll to a halt at the end of the runway -- all without human intervention.

Autopilot programs were first created to make planes fly more smoothly and reduce pilot distractions by taking over rote tasks. Today's software also handles many other vital aspects of flight, such as adjusting cabin air pressure, maximizing fuel efficiency and warning of impending mechanical breakdowns or collision threats.

Advances planned for the Airbus A380 superjumbo jet, due to start passenger service later this year, and Boeing's long-range 787 Dreamliner, due in 2008, will take automation to new heights. Instead of independent hardware and software systems for each task, the new jets will save weight by relying on redundant central computers to run the whole plane. The systems will have safeguards to prevent programs from interfering with and confusing each other. For example, if speed readings from sensors differ widely, the computers are designed to disregard the most extreme measurement and try to figure out which reading is correct.

Safety professionals agree that steady progress in onboard computing is a major reason accident rates for jetliners have declined significantly in the U.S. and much of Europe over the past two decades. In North America, there were 1.3 crashes per million departures in the late 1980s. By 2004 and 2005, the average figure was about 0.4, meaning the chance a plane now taking off will crash is less than one in two million.

Nonetheless, the design of computer systems intended to eliminate cockpit mistakes carry their own hidden risks of human error. In February 2005, multiple computers meant to back each other up mistakenly cut the flow of fuel to two of the four engines on a packed Virgin Atlantic Airbus A340 headed from Hong Kong to London. The crew made an emergency landing at Schiphol Airport outside Amsterdam. British investigators have recommended design changes, including better warnings on fuel levels. Virgin Atlantic says it is cooperating with the investigation and the safety of the passengers was never threatened.

Last October, a 90-second computer hiccup aboard a British Airways Airbus A319 on a night flight from London to Budapest temporarily shut off nearly all the cockpit lights and electronic displays, along with radios and autopilot systems. British investigators say they have unearthed four similar cases on Airbus jets.

A British Airways spokesman says the airline worked with Airbus to diagnose the problem but they were unable to replicate the glitch. Airbus declines to comment on the two incidents because they remain under investigation. Airbus is 80%-owned by European Aeronautic Defence & Space Co. and 20%-owned by Britain's BAE Systems PLC.

During a test flight of a new jetliner made by Brazilian plane manufacturer Empresa Brasileira de Aeronáutica SA, or Embraer, the cockpit screens went black for a minute because of a software glitch. The FAA has since ordered programming and operational changes to the planes. Embraer says it has fixed the problems. Similar computer malfunctions have caused all cockpit screens to flicker or go dark momentarily in some smaller jets used by business executives. Regulators and manufacturers are working to prevent the same type of glitches on other high-end corporate aircraft.

The recent focus on computer problems partly reflects success in mitigating the more traditional dangers of flying such as pilot error, engine failure and bad weather. To keep pilots fresh, airlines have limited the number of hours they can work. Radar maps the precise location and intensity of storms.

Mechanical components such as jet engines are just as complex in their own way as computers. But aviation engineers now have an exhaustive understanding of the physical properties of metals, plastics and other materials and they know how to test them together as a system. That helps the industry produce parts that can handle the stresses of wind, turbulence and landing. Such parts almost never fail so long as they're properly maintained and operated.

In designing the superjumbo A380, Airbus engineers across Europe spent months bending and banging physical components of the aircraft to replicate the stresses of flying and landing. Ultimately they broke the parts, determining the maximum load the plane could handle. Engineers used that information to set operating limits such as top speed.

However, engineers can't predict as easily what kind of stresses might cause a computer program to go haywire. "Software is different," says Gérard Ladier, the senior manager of software engineering at Airbus.

Airbus has put huge effort into vetting the electronics, or avionics, of the new plane, which is the largest passenger jet ever built. At Airbus's headquarters in Toulouse, France, the guts of the A380 -- a collection of wires, pipes and motors -- lie in a gymnasium-sized room like a dissected robot. For two years before the jet's first flight in April 2005, engineers used this "iron bird" to check how their computers controlled the plane's mechanical systems.

Specialists say the biggest problems in aviation software don't stem from bugs in the code of a single program but rather from the interaction between two different parts of a plane's computer system. In extreme cases, foul-ups can lead to sudden loss of control, sometimes not showing up until years after aircraft are introduced into service.

Continued in Part 2
 
Last edited:

WinterHawk

Member
Jan 18, 2004
706
1
18
Cyberspace
With commerical software the rush is on to get it out the door and to start recouping those development costs. Testing is rushed and problems are missed because pressure to be the first on the market.

There is a reason why Military software takes so long to get into the field, it's tested to a degree that an commercial company would find unacceptable. If it doesn't work all the time, perfectly, predicatbly, someone may die.

And this is an example, to get the contract, to be the first on the market, short cuts were taken, assumpations were made and thankfully no one had to pay the price this time. Even Mircosoft is finding out that it just takes time to get a new product out to market. You have to test, test and retest.

There is a reason why Banks and Insurance companies all still rely heavly on Mainframe technology that is in some cases 30 or more years old. It works, its tested, its known, its dependible.

Three cheers for COBOL!!!
 

l69norm

Member
Jan 25, 2004
707
0
16
Airbus to use computers to avoid mid-air collisions

http://online.wsj.com/public/articl...BWnPQ6U554_20070528.html?mod=tff_main_tff_top

Airbus Planes to Use Computers
In Crash-Avoidance Maneuvers
By ANDY PASZTOR
May 27, 2006; Page A4

European jet maker Airbus is taking an unprecedented step to expand cockpit automation: onboard computers that will automatically maneuver jetliners to avoid midair collisions, without any pilot input.

Known for its pioneering use of computers and software to push the automation envelope, this time Airbus has decided to cross a new threshold in replacing pilot decisions with computer commands. For the first time, flight crews of Airbus planes will be instructed and trained to rely on autopilots in most cases to escape an impending crash with another airborne aircraft. Currently, all commercial pilots are required to instantly disconnect the autopilot when they get an alert of such an emergency, and manually put their plane into a climb or descent to avoid the other aircraft.

The change, which hasn't been announced yet, comes after lengthy internal Airbus debates and despite skepticism from pilot groups and even some aircraft-equipment suppliers.

In spite of significant pilot opposition, the proposed shift sets the stage for broader use of computerized safety systems down the road to protect commercial planes, business jets and other aircraft from other hazards, including flying into natural or man-made obstacles.

Airbus, a unit of European Aeronautic Defence & Space Co. and BAE Systems PLC, plans to start installing the computerized systems on its A380 superjumbo jets perhaps as soon as next year, pending regulatory approvals. It intends to gradually install them on all other Airbus aircraft, including retrofits for older models.

The proposed systems will ensure that all aircraft "respond correctly and quickly" to alerts with "less stress on the pilot [and] less potential for injury" to passengers, said Bill Bozin, a top Airbus safety official. He said some pilots now overreact to such cockpit alerts, making extreme maneuvers that can throw passengers around, and in congested airspace even end up putting the aircraft on a collision course with still other nearby planes. In rare circumstances, pilots would retain the option of turning off the autopilot and responding on their own.

The average passenger probably won't notice any difference in an emergency, but the concept already is prompting a fair bit of controversy in aviation circles. Larry Newman, a top safety official with the Air Line Pilots Association, said his group is wary because "this tends to lead to getting the pilot further and further away from the process" of responding to emergencies.

The design approach used by Airbus -- essentially trusting computers to react faster and more predictably than humans to midair alerts and then revert to normal flight -- is in stark contrast to Boeing Co.'s approach of relying on pilot judgment in all emergencies. Before Airbus publicly talked about its decision, Scott Pelton, Boeing's chief engineer for electronic systems on jetliners, said Boeing would remain "aligned with our fundamental philosophy," which "believes the captain is in charge."
 

l69norm

Member
Jan 25, 2004
707
0
16
Microsoft Windows coming to a device near you

gottagetsomeluvin said:
That's scary....I am glad Microsoft is not creating customized software ... Blue Screen of Death? :eek:
Windows CE is starting to become popular as an embedded OS into both consumer and industrial devices.

I once saw a commercial ethernet switch/router that used Windows NT as an OS.

I'm told that it would sometimes "Blue Sceen" and stop working until you rebooted it. Needless to say, it's no longer made, but you can still find them on ebay:

http://cgi.ebay.ca/HUGE-LOT-Fore-Ma...ryZ71526QQssPageNameZWD1VQQrdZ1QQcmdZViewItem
 
Last edited:

l69norm

Member
Jan 25, 2004
707
0
16
Part 2 Incidents Prompt New Scrutiny Of Airplane Software Glitches

This is part 2........

http://online.wsj.com/article/SB114895279859065931.html
http://64.226.131.145/discus/message...tml?1149018014

The Wall Street Journal

Incidents Prompt New Scrutiny Of Airplane Software Glitches

As Programs Grow Complex, Bugs Are Hard to Detect; A Jet's Roller-Coaster Ride

Teaching Pilots to Get Control

Continued from Part 1:

Malaysia Airlines Flight 124 is a case in point. Boeing's 777 jets started service in 1995 and had never experienced a similar emergency before. According to Boeing and Honeywell, the source of the problem was a revised computer program that had recently been installed on all 777s to fix a minor navigation flaw.

Honeywell and Boeing didn't know that the new program had a defect: It simultaneously told the autopilot that the plane was flying dangerously slow and much too fast. Investigators are still trying to figure out what circumstances triggered the program to give the conflicting data. Flight computers struggled to respond, and the plane's speed plunged to 150 knots from 270 knots. The control column shook to warn of an impending stall.

Soon after the incident, Boeing issued a safety alert advising that, in such circumstances, pilots should immediately disconnect the autopilot and might need to exert an unusually strong force on the controls for as long as two minutes to regain normal flight.

Frank McCormick, a former Boeing software engineer, isn't surprised that such a flaw slipped through testing. "The notion that we can anticipate every eventuality is delusional," says Mr. McCormick, who now runs Certification Services Inc., a consulting firm in Eastsound, Wash., that advises a number of manufacturers and the FAA.


Airbus, Boeing and others are trying harder to prevent malfunctions. U.S. airlines, jet manufacturers, software suppliers, regulators and pilots unions recently started a joint initiative to gather data about past computer-related incidents in order to analyze them in detail. The group also plans to dissect commercial crashes going back many years to see whether overlooked computer malfunctions may have played a role.

The goal, says Ms. Gilligan of the FAA, is to determine whether there is "a latent risk from automation that hasn't yet manifested itself."

Manufacturers are also improving the design process for aviation software. Some computer glitches may be caused by extreme weather or altitude, says Mr. Pelton, Boeing's chief engineer for electronic systems. When neutrons at high altitude bombard on-board computers, they can temporarily affect chip memories. To compensate, Boeing and its suppliers use error-detection circuits to "design out the problem nature introduces at high altitudes," Mr. Pelton says.

Manufacturers also are adding more automated test procedures, and enhancing verification processes for software such as intentionally cutting off the main power to test whether backup electricity keeps the systems running steadily.

While eliminating every last bug is difficult, Boeing's aim is to create automated systems that will protect the plane or at least notify the crew that something is wrong, Mr. Pelton says. Both Boeing and Airbus back up sophisticated computers with simpler ones that indicate the heading, speed and orientation of the plane. This gives pilots enough information to continue flying in the event of widespread system failure.

For every hour of software development at Honeywell, 20 minutes are spent checking for potential problems and "fixing the stuff that went wrong," says Randy Robertson, a senior Honeywell software engineer.

Safety specialists are also trying to improve how cockpit crews handle automated systems. Like any office worker with a computer, pilots know how to use the programs needed for their job -- but few are trained to understand computers in detail or to troubleshoot them. Even during normal operations, flight crews frequently grumble about what the mysterious equipment is doing.

Some accident investigators and safety experts say pilots need more training in how to react when software malfunctions badly. In such cases, flight controls may feel completely different from normal. "Those are the kinds of things we need to experience first in the simulator," says Larry Newman, a senior safety official with the Air Line Pilots Association, the largest U.S. union representing pilots.



Write to Daniel Michaels at daniel.michaels@wsj.com and Andy Pasztor at andy.pasztor@wsj.com

URL for this article:
http://online.wsj.com/article/SB114895279859065931.html
 

l69norm

Member
Jan 25, 2004
707
0
16
Military Aircraft Software Bugs

WinterHawk said:
..There is a reason why Military software takes so long to get into the field, it's tested to a degree that an commercial company would find unacceptable....
Military aircraft have bugs as well:

A YF-22 Raptor prototype crashes due to flight computer bug:
http://www.csd.uwo.ca/~pettypi/elevon/baugher_us/f022.html
http://212.204.242.91/media/FA-22_runw_crashlanding.mpeg

...Unfortunately, N22YX was involved in a major accident on May 25, 1992 when it belly-flopped onto the runway after 8 seconds of violent pilot-induced oscillations. It slid several thousand feet down the runway and caught fire, destroying some 25 percent of the airframe. Pilot Tom Morgenfeld was uninjured, but the aircraft was deemed too badly damaged for economical repair.

At the time of the crash, Morgenfeld had been carrying out a planned go-around, and he had just switched on his afterburners and had retracted his undercarriage at less than 50 feet off the runway with thrust vectoring active. At a speed of 175 knots, the aircraft began an uncommanded pitchup followed by a severe stick-forward command from the pilot. The aircraft then entered a series of pitch oscillations, with rapid tail and thrust nozzle fluctuations, exacerbated by control surface actuators hitting rate limiters causing commands to get out of synchronization with their execution.........


A production F-22 crash due to a software bug:
http://www.reviewjournal.com/lvrj_home/2005/Jan-13-Thu-2005/news/25654033.html
http://www.airforcetimes.com/content/editorial/pdf/af.exsum_f22crash_060805.pdf
Computer simlulation of F-22 Crash:
rtsp://real.gannett.speedera.net/real.gannett/atpco/060805_f22crash.rm


http://www.airforcetimes.com/story.php?f=1-292925-901323.php
Power loss, vague instructions
caused December Raptor crash

By Bruce Rolfsen
Times staff writer

An F/A-22 Raptor crashed Dec. 20 as it was attempting to take off from Nellis Air Force Base, Nev. The jet wobbled and then flipped over. This Air Force photograph, taken from the southwest, shows where the jet crashed back onto the runway, foreground, and then skidded to a stop.

A loss of electrical power and vague instructions helped lead to the crash of an F/A-22 Raptor as it was taking off from Nellis Air Force Base, Nev., on Dec. 20, according to an Air Combat Command investigation released June 8.

The jet’s pilot, Maj. Robert A. Garland of the 422nd Test and Evaluation Squadron at Nellis, survived the crash by ejecting before the stealth jet flipped over and skidded across the ground.

The crash was the first of an F/A-22 and came as the service battled to save the fighter program from budget cuts.

The accident investigation board found that an electrical power interruption caused three sensors that monitor the plane’s pitch, yaw and roll to stop sending information. Without information from the sensors — called “rate sensor assemblies” — the F/A-22 is uncontrollable once it leaves the ground.

Garland didn’t realize the sensors had been turned off because he had done his avionics check, called the “initiated built-in test,” before the power interruption. Garland realized he had lost control of the jet as he took off.

Prior to the accident, the Air Force and F/A-22 contractor Lockheed Martin were aware there were problems with the rate sensor assemblies and began to retrofit them in June 2004, the report said.

The Air Force also has rewritten F/A-22 technical orders to make it clear that the avionics checks must performed when engines are restarted.

Garland performed his check when the two engines were started, but did not do a second check after he shut down the engines while mechanics fixed an unrelated problem. Garland thought there had been no break in electrical power to the sensors as the plane switched from engine-driven electrical generators to the auxiliary power system, according to the report.
 

gottagetsomeluvin

New member
May 25, 2006
105
0
0
Everywhere
No matter what, anytime a software is released, there will always be bugs. They can't catch everything, especially in complicated software, or in a simulated environment.

All QC tries to do is make sure all the 'critical' bugs are caught, which is something MS has neglected to understand, it's all about being out first and fixing it later, and people were stupid enough to accept it.

But even customized software follow the same guideline since most of the 'project' sponsors get bonuses based on making a release date, so they can have their big parties and look really good to upper management. Again, usually 'critical' bugs are caught. Working in the banking and insurance industry as a consultant, I see this all the time. No software will ever be release with 100% bug free. There will always be some minor ones.

Either way.. I have to say, I feel safer flying in a plane than driving in Toronto. You think they will have an 'emergency' button in a car one day to avoid accidents? :D
 

SilentLeviathan

I am better than you.
Oct 30, 2002
909
0
16
gottagetsomeluvin said:
That's scary... I spend half my time on planes....

I am glad Microsoft is not creating customized software for airlines...

oh.. oh.. Blue Screen of Death? :eek:
Micrsoft makes most of the software for cars. Not engine management software but stuff like the touch screen software and controlling how various components interact with eachother.
 

l69norm

Member
Jan 25, 2004
707
0
16
gottagetsomeluvin said:
...Either way.. I have to say, I feel safer flying in a plane than driving in Toronto. ..
l69norm said:
...."Safety professionals agree that steady progress in onboard computing is a major reason accident rates for jetliners have declined significantly in the U.S. and much of Europe over the past two decades. In North America, there were 1.3 crashes per million departures in the late 1980s. By 2004 and 2005, the average figure was about 0.4, meaning the chance a plane now taking off will crash is less than one in two million"...
Yes, it's a risk vs. benifits thing. Over the last 20 years, flight software in airliners has reduced the risk of an accident by more than 75%.
 
Last edited:

l69norm

Member
Jan 25, 2004
707
0
16
Just for fun, more Military Videos

Just for fun, I can across these interesting videos:

F-22 test flight:
http://www.youtube.com/watch?v=qphv...itaryphotos.net/forums/showthread.php?t=82103


Person being sucked into the jet intake of a Navy A-6 Intruder getting ready for take-off:
http://www.alexisparkinn.com/photogallery/Videos/sucked in engine.avi

The guy survived and climbed out of the intake a few mins later:

"Regarding the video "Sucked into an Engine", on your website, you write that you are uncertain about the authenticity of the video. I can attest that it is true as I was on the ship when it happened."

"What you see in the video is a trainee checking the position of the launch bar in the shuttle and then moving away from the aircraft. The guy that gets sucked in his trainer and goes in to double check the launch bar position. He made a mistake by walking straight toward the nose gear which put him in front of the intake. He should have gone behind the intake and looked forward into the shuttle. All of this is happening with the engines at full throttle, by the way."

"I was attached to VFA-15 onboard the USS Theodore Roosevelt during that deployment in 1991. This occurred just after Desert Storm. He did survive and I'm surprised the editors of that video didn't include him climbing out. What allowed him to survive was the design of the A-6 engine (the J-52). It has a long protruding 'bullet' or cone that extends in front of the first stage fans. When he was sucked in, his arm extended above his head which caused his body to wedge between the bullet and inside wall of the intake. Lucky for him, his cranial and float coat were sucked in first causing the FOD'd engine which prompted the pilot to cut the throttle (commanded by the Shooter who moves into the frame kneeling and moving his wand up and down). It took almost 3 minutes for him to push his way out of the intake after being sucked in. Needless to say, I don't think he was seen on the flight deck for the rest of the cruise."

Commentary on this video from "Skids": "At the time of this incident I was an intel officer in Attack Squadron 65, the squadron which the A-6E in this video was attached to. xxxx - account is accurate, except that this incident actually occurred during Operation Desert Storm as the date on the video 02-20-91 shows. The aircraft was fully loaded for a night combat mission into Iraq -- if you look carefully at second 00:24, you can see 2 Mk-84 2000lb bombs under the port wing."

"The pilot, 'Gilly', immediately knew that he got FOD’d and shut down the engine. What nobody new was that the FOD was the trainer who was sucked in, until he crawled out, dazed, confused, and without all his gear a couple of minutes later. He suffered minor head injuries and a broken collar bone."
 
WinterHawk said:
There is a reason why Military software takes so long to get into the field, it's tested to a degree that an commercial company would find unacceptable. If it doesn't work all the time, perfectly, predicatbly, someone may die.
Boeing, Gen. Dynamic, BAE & various miltary contractors are under same pressure to be faster to market & quarterly returns. No difference. In the case of military failures, most of it are covered up.

There was one few months ago, with missiles locked on jumbo jet mistaken it for incoming fighter jets.
 
l69norm said:
Such glitches, while extremely rare, are emerging as a top safety challenge in the air. With well over five million lines of code used on the latest jetliners, versus fewer than a million on older planes, it's increasingly difficult to detect and fix embedded problems before they surprise pilots.
There was the one with combo of s/w & human error, Russian airline 747 vs. DHL freight jet collision. The software told both planes to head for each other. Discovery channel has a documentary on it.
 

l69norm

Member
Jan 25, 2004
707
0
16
goodtime said:
There was the one with combo of s/w & human error, Russian airline 747 vs. DHL freight jet collision. The software told both planes to head for each other. Discovery channel has a documentary on it.
http://news.scotsman.com/topics.cfm?tid=455&id=738632002

Jet pilot’s 14 seconds dilemma before fatal crash
PAUL GALLAGHER

THE pilot of the doomed Russian passenger jet in last week’s mid-air collision over Germany had 14 seconds to choose between contradictory instructions immediately before the crash which killed 71 people, it emerged last night.

A flight-voice recorder obtained from the wreckage of the Tupolev-154 aircraft has revealed the cockpit proximity warning system initially ordered him to pull the aircraft up to avoid a collision.
Advert for the new Scotsman jobs site

Just one second later, he received a contradictory radio instruction from a Swiss air-traffic controller telling him go into a dive.

There was silence for 14 seconds, as the pilot faced an agonising dilemma, before the air-traffic controller sent another radio message repeating the instruction to take the plane into a descent.

The pilot obeyed the control instruction and over-rode his cockpit warning to begin his descent from 36,000ft. Just 30 seconds later, his aircraft slammed into a Boeing 757 cargo plane crossing his path.

A separate examination of the Boeing 757 voice recorder has shown that its pilot had also received an automatic proximity warning at exactly the same time as the Tupolev-154 pilot. The computer system had correctly ordered the Tupolev-154 to climb and the Boeing 757 to dive so the collision would be avoided.

The discovery of the contents of the flight voice recorders will place further pressure on the Swiss air traffic controllers who had responsibility for the two aircraft at the time of the collision on 1 July.

Although the collision took place over southern Germany, it was on an approach to Zurich airport and the flightpaths were controlled by air-traffic controllers in Zurich.

Swiss air-traffic control said the Zurich tower would have had no way of knowing the pilot was receiving a contradictory instruction from his cockpit warning system - or Traffic Control Advisory System (TCAS).

"He only finds out about it if the pilot tells him," spokesman Markus Luginbuehl said. "If the pilot reacts to a TCAS alarm, he is supposed to advise the controller. And the pilot assumes responsibility for the manoeuvre."

Russian aviation officials, Bashkirian Airlines and Moscow’s Domodedovo Airport, where the Russian flight started, said in the case of a contradiction between the on-board, anti-collision system and air-traffic control instructions, ground command had priority.

"The air-traffic controller gets the last word," said Sergei Rybanov, of Bashkirian Airlines.

But Herbert Schmell, a spokesman for the national airline, Swiss, said the cockpit-warning system should have been obeyed over ground control. "A TCAS system makes no sense if it is overruled, especially in a phase when there isn’t much leeway any more," Mr Schmell said.

Skyguide, the private company that operates air-traffic control in Switzerland, initially claimed the pilot had been warned up to two minutes before the crash and had "repeatedly" ignored the instruction. It later revised the margin down to 50 seconds.

The voice recorder reveals the time of the first Skyguide instruction to dive was actually given 44 seconds before impact. It also offers a possible explanation for the pilot’s 14-second hesitation as he deliberated which of the contradictory orders to follow.

Other factors being examined include the fact that an automatic collision-alert system at Zurich air-traffic control tower was switched off at the time of the crash and only one air-traffic controller was on duty. It also emerged yesterday that German air-traffic controllers had tried to warn Skyguide the planes were on a collision course but the telephone network was down.

The head of the Swiss Air Accident Investigation Bureau still suggested the Russian pilot may have been at fault when asked about the findings yesterday. Jean Overney said he didn’t know what rules Russian pilots have to follow in the case of a conflict between instructions from air-traffic controllers and the plane’s own collision avoidance system.

Mr Overney said: "In the West, the pilot must follow the collision avoidance system."

All 69 people, including 45 schoolchildren, aboard the Russian Tupolev-154, and two crew members on the Boeing 757 were killed when the aircraft collided
 
Ah, yes. It was Swiss Air traffic control. Didn't catch the entire doc but suggest Traffic control guy was partly at fault, left the 2 planes to fend for themselve as he was too busy with resolving another conflict with 2 other planes. While traffic control from another airport couldn't get through to warn them.
 

l69norm

Member
Jan 25, 2004
707
0
16
Discovery Channel

goodtime said:
Ah, yes. It was Swiss Air traffic control. Didn't catch the entire doc but suggest Traffic control guy was partly at fault, left the 2 planes to fend for themselve as he was too busy with resolving another conflict with 2 other planes. While traffic control from another airport couldn't get through to warn them.
The Discovery Channel had the doc on again. It was part of a show called "Mayday".

The investigation cleared the controller, it turned out that it was a procedural problem !!

He was the only controller on duty, but he had to go back and forth between two different radar consoles to cover his area. He could not read the radar screen of one console from the other. Senoir managment knew this was a problem with this, but did nothing to correct this.

It also turned out that they were doing system maintenance on his radar at the time and they turned off his anti-collision radar warning system without telling him. He never got the alarm to tell him that these planes were about to collide.

Not only that, but he realized that he was being going to be overloaded and he tried to hand flights off to the next control center. He found both his main and backup phones weren't working due to the same system maintenance !!!

The next control center did get the radar anticollison warning for these planes and was desperaterly trying to contact the controller via that same downed phone system.

The controller somehow did spot the problem and radioed new instructions to try to seperate the planes. Thinking that he had solved the problem, he was then on his radio with instructions to a third plane.

The DHL pilot also realized something was wrong and tried to call the controller back for 20 seconds but frequency was busy because the controller was still on his radio with the third plane.

About 20 sec later, the planes collided.

The tragedy continued. The father of one of the dead children was allowed to search the crash site. He actually found the body of his 4 year old daughter in the wreckage (his son and wife were also killed in the crash).

He was so tramatized by this that he later murdered the air traffic controller who he blamed for his family's death:

http://newsfromrussia.com/world/2005/10/26/66272.html
 
Toronto Escorts