PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   Spanair accident at Madrid (https://www.pprune.org/rumours-news/339876-spanair-accident-madrid.html)

p51guy 22nd Aug 2010 23:41

I can't find the electrical schematic of how the TAT and TWS works but it was posted here hundreds of posts ago. Maintenance disabled the TAT but didn't realize the R5 relay also affected the take off warning system. More knowledge of the systems might have prevented this crash. The R5 relay plug in receptacle might have been corroded and removing it and testing it might have not proven anything. The corrosion in the receptical was probably the reason for the failure. Spending many years working on electronic devices I have found once you move a device everything changes. All the evidence goes away. Sometimes temperature, vibration and moisture can change how electronic things work. They could test it still in it's socket but after the jolt it got crashing it might have jiggled back to working condition. R5 is the most likely cause of the failure of the take off warning system. If someone can find the post with the schematic please post it.

glad rag 22nd Aug 2010 23:57

I remember that diagram when it was posted, but I disagree with your hypothesis in post #2612.

protectthehornet 23rd Aug 2010 01:34

Let us all just learn some things, OK?

1. Always check the killer items prior to taking the runway for takeoff...flaps/slats, trim, flight controls free and correct and all the stuff we wrote about months ago.

2. On any plane, you need to know certain symptoms. If something isn't right, maybe the plane thinks its in the air. I wonder where the landing gear over ride button was during taxi out.

3. if you aren't flying well on takeoff and all engines are working, and you might be stalling...put down some flaps/slats.

P51 guy is on the right track, whether it is a relay or not...but always check things, just like a doctor with a patient.

I love the DC9 series. I've seen the RAT/EPR gauge show the wrong readings at the gate and lo and behold, the plane thought it was in the sky for whatever reason.

Be careful...it is what you are paid to do.

PJ2 23rd Aug 2010 02:40

p51guy;

You can use the search feature to perhaps find the graphic, using "schematic" as a key search word. Or you can read the first interim report here, and a short second interim report at the same site, both available in English.

I think it is short-sighted to state that the R2-5 relay was "at fault" even though we may know that the TOWS did not perform as designed. A similar claim regarding the Radio Altimeter is made for the Turkish B737 accident at AMS - it may have been a factor, but other, more serious issues were also involved. The logical conclusion to such a proposition is to "focus on MD80 R2-5 relays to ensure their contacts are clean and that they're fastened securely", etc etc, when often these things are far more complicated and causal factors more deeply hidden than first appears.

Checklist interruption, already discussed above, is one such factor. A standard SOP for any interruption during the use of memorized checklists for example, is to start them over again from the beginning. The only exception to this is when using a mechanical checklist where open items may be clearly seen and not merely remembered as "not cleared".

PJ2

p51guy 23rd Aug 2010 03:31

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.

forget 23rd Aug 2010 08:37


I can't find the electrical schematic of how the TAT and TWS works ...
This it?

http://i21.photobucket.com/albums/b270/cumpas/RAT2.jpg

glad rag 23rd Aug 2010 11:34

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

forget 23rd Aug 2010 11:48


... the switching logic of the series connected microswitches doesn't seem to be shown?
Aircraft schematics are always shown with no power, aircraft on ground - unless noted otherwise; and/or modified as in the lower of the two shown.


is this diagram correct??
Works for me.

Lonewolf_50 23rd Aug 2010 12:14


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.
Aha, that makes sense, and makes the article make sense to me. Thanks! :ok:

This does NOT mitigate the errors by the crew.
Aye.

p51guy 23rd Aug 2010 12:57

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.

glad rag 23rd Aug 2010 13:45


Aircraft schematics are always shown with no power, aircraft on ground
True enough you can't go swapping the drawing standards about willy nilly, complete confusion will follow.

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

p51guy 23rd Aug 2010 14:54

Looking for a final report on the crash found it is due in December. Found the malware in the maintenance central computer info however.

Lonewolf_50 23rd Aug 2010 15:06

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. :eek: Could happen to anyone ...

p51guy 23rd Aug 2010 15:09

By Leslie Meredith
http://msnbcmedia3.msn.com/j/MSNBC/C...y.standard.gif
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.

hetfield 23rd Aug 2010 16:41

Oh infected computers, what a pitty....
:ugh:

BOAC 23rd Aug 2010 16:57

Lonewolf - Posts #2622 and 2623 are what you need.

Lonewolf_50 23rd Aug 2010 18:01

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)

Old_Fokker 23rd Aug 2010 20:19

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!

p51guy 23rd Aug 2010 22:36

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?

BOAC 24th Aug 2010 07:09


starting the confusion
- the original article in the Register was pretty clear about it! Perhaps time to abandon 'TechNewsDaily'?


All times are GMT. The time now is 22:11.


Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.