Spanair accident at Madrid
Join Date: Jun 2009
Location: US
Posts: 497
Likes: 0
Received 0 Likes
on
0 Posts
PJ2, I agree, the relay and radio altimiter didn't cause those two crashes, the pilots did. Their backup failed in both cases letting their mistakes go unnoticed. Pilots should not expect automatic warnings to correct their mistakes. As previously stated always do a final check mentally on take off and landing of the two or three things that matter most. Flaps, trim on takeoff and gear, flaps and spoilers armed for us for landing. We lost one due to spoilers not being armed along with other things so added that.
Join Date: Aug 2007
Location: London, New York, Paris, Moscow.
Posts: 3,632
Likes: 0
Received 0 Likes
on
0 Posts
Hmm if that's the standard of diagrams from the AMM no wonder things were confusing the mechanics, the switching logic of the series connected microswitches doesn't seem to be shown? is this diagram correct??
Is the ToW a MEL item????
Is the ToW a MEL item????
Join Date: Jul 1999
Location: 58-33N. 00-18W. Peterborough UK
Posts: 3,040
Likes: 0
Received 0 Likes
on
0 Posts
... the switching logic of the series connected microswitches doesn't seem to be shown?
is this diagram correct??
I do not see reference to the a/c 'computer' in the article. The reference as I see it is to the maintenance computer at HQ which should have triggered action, possibly a grounding pending investigation, after 3 similar failures on a particular airframe. It is suggested the computer did not issue the action so the a/c continued in service.
This does NOT mitigate the errors by the crew.
Join Date: Jun 2009
Location: US
Posts: 497
Likes: 0
Received 0 Likes
on
0 Posts
Thanks forget, that schematic is better than the one I remember. Now I see which computer you were talking about , the one at maintenance HQ. Yes, if R2-5 failed the maintenance computer should have required a replacement. Apparently the mechanics didn't enter the problem accurately if the computer was programmed correctly. They may have entered it as a TAT probe heater failure which it wasn't. It must be in the report.
Join Date: Aug 2007
Location: London, New York, Paris, Moscow.
Posts: 3,632
Likes: 0
Received 0 Likes
on
0 Posts
Aircraft schematics are always shown with no power, aircraft on ground
But that is a FUNCTIONAL digagram that really does not show the correct positioning of ALL the elements in that particular circuit.
Whilst pedantic (perhaps) it also goes to illustrate what has (or had) been covered earlier in the thread about about the AMM.
rgds
GR
Is it as the article says, or is there more specificity? Can you share it here?
EDIT: Sorry for the impatience, and thanks for the excerpt from the article. Most informative, and somewhat chilling.
Could happen to anyone ...
EDIT: Sorry for the impatience, and thanks for the excerpt from the article. Most informative, and somewhat chilling.
Could happen to anyone ...
Join Date: Jun 2009
Location: US
Posts: 497
Likes: 0
Received 0 Likes
on
0 Posts
By Leslie Meredith
updated 8/20/2010 4:48:01 PM ET
Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware.
An internal report issued by the airline revealed the infected computer failed to detect three technical problems with the aircraft, which if detected, may have prevented the plane from taking off, according to reports in the Spanish newspaper, El Pais.
Flight 5022 crashed just after takeoff from Madrid-Barajas International Airport two years ago today, killing 154 and leaving only 18 survivors.
The U.S. National Transportation Safety Board reported in a preliminary investigation that the plane had taken off with its flaps and slats retracted — and that no audible alarm had been heard to warn of this because the systems delivering power to the take-off warning system failed. Two earlier events had not been reported by the automated system.
The malware on the Spanair computer has been identified as a type of Trojan horse. It could have entered the airline's system in a number of ways, according to Jamz Yaneeza, head threat researcher at Trend Micro.
Some of the most likely ways are through third party devices such as USB sticks, Yaneeza said, which were responsible for the International Space Station virus infection in 2008, or through a remote VPN connection that may not have the same protection as a computer within the enterprise network. Opening just one malicious file on a single computer is all it takes to infect an entire system.
"Any computer that is connected to a network is vulnerable to a malware infection," O. Sami Saydjari, president of Cyber Defense Agency, told TechNewsDaily. "Standards have not been set to protect critical infrastructure."
An incident like this could happen again, and most likely will, according to Saydjari.
A judge has ordered Spanair to provide all of the computer's logs from the days before and after the crash.The final report from crash investigators is not due to be presented until December.
I was just getting ready to post it.
updated 8/20/2010 4:48:01 PM ET
Authorities investigating the 2008 crash of Spanair flight 5022 have discovered a central computer system used to monitor technical problems in the aircraft was infected with malware.
An internal report issued by the airline revealed the infected computer failed to detect three technical problems with the aircraft, which if detected, may have prevented the plane from taking off, according to reports in the Spanish newspaper, El Pais.
Flight 5022 crashed just after takeoff from Madrid-Barajas International Airport two years ago today, killing 154 and leaving only 18 survivors.
The U.S. National Transportation Safety Board reported in a preliminary investigation that the plane had taken off with its flaps and slats retracted — and that no audible alarm had been heard to warn of this because the systems delivering power to the take-off warning system failed. Two earlier events had not been reported by the automated system.
The malware on the Spanair computer has been identified as a type of Trojan horse. It could have entered the airline's system in a number of ways, according to Jamz Yaneeza, head threat researcher at Trend Micro.
Some of the most likely ways are through third party devices such as USB sticks, Yaneeza said, which were responsible for the International Space Station virus infection in 2008, or through a remote VPN connection that may not have the same protection as a computer within the enterprise network. Opening just one malicious file on a single computer is all it takes to infect an entire system.
"Any computer that is connected to a network is vulnerable to a malware infection," O. Sami Saydjari, president of Cyber Defense Agency, told TechNewsDaily. "Standards have not been set to protect critical infrastructure."
An incident like this could happen again, and most likely will, according to Saydjari.
A judge has ordered Spanair to provide all of the computer's logs from the days before and after the crash.The final report from crash investigators is not due to be presented until December.
I was just getting ready to post it.
BOAC: thanks, 23 wasn't all that helpful to me, as it got me to Mr Leyden. Perhaps my brain was looking for an acft computer issue and so I read that into the article. 22 got me only a redirect and no site to read ... no probs, usual internet glitches. Subsequent explanation has been most appreciated. 
(I had to run maintenance operations part of a lifetime ago ... having no/bad info to work with is a very unsettling happening)
(I had to run maintenance operations part of a lifetime ago ... having no/bad info to work with is a very unsettling happening)
Join Date: Jun 2008
Location: Spain
Age: 58
Posts: 28
Likes: 0
Received 0 Likes
on
0 Posts
Alleged Malware word of caution
This story is now rapidly spreading across the internet. Most, if not all, state the El Pais newspaper as their source. Turns out that the original El País article does not make the assumptions nor draw the conclusions others which refer to it do.
From the TechNewsDaily article quoted by p51guy:
"An internal report issued by the airline revealed the infected computer failed to detect three technical problems with the aircraft, which if detected, may have prevented the plane from taking off, according to reports in the Spanish newspaper, El Pais."
That is not what the original article said. No where near it in fact. For the computer system to detect three technical problems and raise an alarm, it would first have to be aware there had been 2 previous incidents. It was not because Spanair had the bad habit of registering incidents 24 hours later, as the El País newspaper does state.
In fact, as El Pais states, it was when the technicians tried to report the latest incident, they found they could not do so because of the malware. At this time, as El Pais stresses, the plane had already crashed.
I've seen this "Malware caused plane to crash" news-item rapidly evolve over the past 24 hours. Another perfect example of how 'journalists' appear to drop all their journalistic integrity (should they have any) the moment they need to address an issue they do not understand). As far as I have been able to find out, most if not all of the confusion regarding the original El País article is based on a (very bad) Google Translation. Some newspapers, like dutch De Telegraaf (most read in Holland) even claim the plane's boardcomputer was infected!
Bottom line: don't use Google Translate!
From the TechNewsDaily article quoted by p51guy:
"An internal report issued by the airline revealed the infected computer failed to detect three technical problems with the aircraft, which if detected, may have prevented the plane from taking off, according to reports in the Spanish newspaper, El Pais."
That is not what the original article said. No where near it in fact. For the computer system to detect three technical problems and raise an alarm, it would first have to be aware there had been 2 previous incidents. It was not because Spanair had the bad habit of registering incidents 24 hours later, as the El País newspaper does state.
In fact, as El Pais states, it was when the technicians tried to report the latest incident, they found they could not do so because of the malware. At this time, as El Pais stresses, the plane had already crashed.
I've seen this "Malware caused plane to crash" news-item rapidly evolve over the past 24 hours. Another perfect example of how 'journalists' appear to drop all their journalistic integrity (should they have any) the moment they need to address an issue they do not understand). As far as I have been able to find out, most if not all of the confusion regarding the original El País article is based on a (very bad) Google Translation. Some newspapers, like dutch De Telegraaf (most read in Holland) even claim the plane's boardcomputer was infected!
Bottom line: don't use Google Translate!
Join Date: Jun 2009
Location: US
Posts: 497
Likes: 0
Received 0 Likes
on
0 Posts
The way she wrote it I don't think Leslie, who wrote the article knew the computer wasn't on the airplane but in the maintenance facility. The follow up reports are equally confusing on what computer where. I had no idea the computer post I initially responded to was in some building, not in the aircraft. I think she is unfamiliar with airline maintenance and wrote it the best she could understand it, starting the confusion. So what else is new?
Join Date: May 2004
Location: Granada, Spain
Posts: 218
Likes: 0
Received 0 Likes
on
0 Posts
I joined this thread a long time ago and was shot down severely by a former MD-80 pilot when I suggested that the crew had just 9 seconds to recover the situation from the time the stall warning sounded to its impact with the ground. The interim accident report reveals that the crew misinterpreted the stall warning horn for a fire alarm and wasted valuable seconds trying to switch it off...I stand by my original suggestion that the aircraft was at least 25kts slow when the aircraft reached the calculated Vr and V2 speeds because the flaps slats were not deployed for take-off and that the clean wing speeds would have been much higher.
However that is not the purpose behind me coming back in here; I need to talk to an Avionics guy specifically someone who has access to the wiring diagrams and or is familiar with the MD-82. I am a retired Avionics engineer and have read the interim accident report several time over, particularly in regard to the operation of the R2-5 relay and its failure history as reported by Boeing in the report. The accident report has been removed from the formento website but I can email a copy if anyone wishes to read it.
This is the point I wish to discuss; On page 39 of the report there is a photograph of the relay panel and specifically R2-5, showing its condition after the crash and I regret that what I see there is one seriously bu**ered up relay, some extremely dodgy wiring and some very dubious working practices. The wiring bears so little resemblance to the wiring diagram I am forced to the conclusion that someone knew that R2-5 on the crash aircraft was suspect long before the crash.
The report also shows graphs taken from the QAR that indicate that the quote 'weight on wheels switch' unquote was working correctly, BUT, the switched ground from the nose wheel is in fact routed through 2 such switches on the nose wheel before being wired to the X2 terminal on the R2-5 relay. I am not familiar with the MD-80 series but my experience is that these switches on other aircraft are invariably in highly exposed areas and subject to all the muck and filth of dirty, sandy, wet runways whilst the relays themselves are in a far more benign environment and that hence the switches rather than the relays are more likely to fail, normally to some indeterminate state, neither one thing or the other.
The aircraft fleet on which I spent almost half my working life on relied heavily on the Leach 9274 series relays and I cannot remember a single instance where one has failed in a 'Weight on Wheels' scenario; however I have had to replace several associated squat switches...
Here is a link to the Leach 9274 series relay manufactures drawing; pages 4and 5 show the pinouts. Compare this with the wiring diagram shown at forgets reply 2634 and the picture on p39 of the accident report...
I'd be happy to discuss this with any avionics people out there.
pp
However that is not the purpose behind me coming back in here; I need to talk to an Avionics guy specifically someone who has access to the wiring diagrams and or is familiar with the MD-82. I am a retired Avionics engineer and have read the interim accident report several time over, particularly in regard to the operation of the R2-5 relay and its failure history as reported by Boeing in the report. The accident report has been removed from the formento website but I can email a copy if anyone wishes to read it.
This is the point I wish to discuss; On page 39 of the report there is a photograph of the relay panel and specifically R2-5, showing its condition after the crash and I regret that what I see there is one seriously bu**ered up relay, some extremely dodgy wiring and some very dubious working practices. The wiring bears so little resemblance to the wiring diagram I am forced to the conclusion that someone knew that R2-5 on the crash aircraft was suspect long before the crash.
The report also shows graphs taken from the QAR that indicate that the quote 'weight on wheels switch' unquote was working correctly, BUT, the switched ground from the nose wheel is in fact routed through 2 such switches on the nose wheel before being wired to the X2 terminal on the R2-5 relay. I am not familiar with the MD-80 series but my experience is that these switches on other aircraft are invariably in highly exposed areas and subject to all the muck and filth of dirty, sandy, wet runways whilst the relays themselves are in a far more benign environment and that hence the switches rather than the relays are more likely to fail, normally to some indeterminate state, neither one thing or the other.
The aircraft fleet on which I spent almost half my working life on relied heavily on the Leach 9274 series relays and I cannot remember a single instance where one has failed in a 'Weight on Wheels' scenario; however I have had to replace several associated squat switches...
Here is a link to the Leach 9274 series relay manufactures drawing; pages 4and 5 show the pinouts. Compare this with the wiring diagram shown at forgets reply 2634 and the picture on p39 of the accident report...
I'd be happy to discuss this with any avionics people out there.
pp
Join Date: Jan 2009
Location: us
Posts: 93
Likes: 0
Received 0 Likes
on
0 Posts
The report also shows graphs taken from the QAR that indicate that the quote 'weight on wheels switch' unquote was working correctly, BUT, the switched ground from the nose wheel is in fact routed through 2 such switches on the nose wheel before being wired to the X2 terminal on the R2-5 relay. I am not familiar with the MD-80 series but my experience is that these switches on other aircraft are invariably in highly exposed areas and subject to all the muck and filth of dirty, sandy, wet runways whilst the relays themselves are in a far more benign environment and that hence the switches rather than the relays are more likely to fail, normally to some indeterminate state, neither one thing or the other
VFD