Looks like a virus was a factor in this accident.


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.




Ally

 

5022 was an MD-80 series (MD-83 I believe). I can't tell from this article if they are suggesting that a virus disabled the takeoff warning system, or if flaps and slats were commanded to take off position and a virus prevented movement but provided a "correct" TO indication.

One theory would suggest an element of, uh.... "human factors". The other is just scary as hell. It hard to imagine a virus overcoming bell cranks, cables, and sequence valves on a non-FBW aircraft.

Anyone have insight as to what factor the virus may have played?

 

Well, in the article it says the computer "failed to detect", which would indicate the computer did not recognize the improperly set takeoff configuration. Nothing in the article suggests the "computer" had anything to do with setting flaps, slats, etc.

 

If only one pax sitting near the wings had noticed during taxi that the flaps were not deployed this accident would have never happened .
I,ll update this again when the final comes out.



Ally

 

I think you guys have mis-read the report.

I may be wrong, but I interpret it that the virus/malware had entered the company engineering and maintenance systems, preventing programs from highlighting a recurrent defficiency on that aircraft relating to a repeat fault in the TOCW system.

The aircraft was not affected itself by a virus.

 

That would make a lot more sense. Thanks!

 

Thanks for the clarification.

Ally

 

When I first read the article I couldn't believe that a modern computer virus would ever find it's way into any vintage MD80 computer system.

Any additional code would probably render a MD80 main system unusable as it would overload it's tiny hard-wired analog brain.

For example, the McDonnell/Douglas factory delivered PMS unit (Perf. Management System) was built by Delco Electronics, a business more commonly known for automotive electronics.

Remember 1980's computer hardware? Probably not, as IBM MS-DOS was only introduced to the marketplace in 1981. Color computer monitors were only introduced in the early '80's.

Bottom line: MD80's have endured as long as they have because of robust DC9 systems and Douglas construction.

Remember: Boeing/Airbus builds airliners - Douglas builds character!

 

Begs the question as to how they forgot to set flaps ,CVR schould be an interesting read in the least.

 

Very basic version, some of which is supposition. The company's computerised maintenance recording system would throw up a warning if the same problem had been recorded for the same airframe on three separate occasions. In this particular case a sensor unit on the nose oleo of the aircraft had been shown to be faulty on two previous occasions.

The sensor reads whether the nose oleo is extended or not. Several different things are dependent on this sensor; the heating elements in the probes; and the takeoff configuration warning is another. In the first the heating elements are turned on when the sensor senses the nose oleo has extended on rotation otherwise they risk burning out on the ground without the airflow to cool them. In the second the takeoff configuration warning is silenced when the sensor senses the oleo has extended as the aircraft has rotated and obviously airborne and therefore a takeoff configuration warning is not required.

On the day of the flight the crew were taxying for takeoff when they became aware that the probes were overheating and they returned to the ramp for the engineers to address the problem. It was found that the nose oleo sensor had failed (this is now the third time on this airframe) and I believe the decision was made to depart with the sensor not working. The crew were to turn the heating elements on after takeoff.

In the rush to depart the now delayed flight the setting of the flaps for takeoff was overlooked. Because the nose oleo sensor was not working the takeoff configuration was also disabled (it thought the aircraft was in flight) and so the crew had no warning of their oversight.

That the maintenance computer had a virus (which I believe disabled the third warning) had no part to play in the crash. The third occurrence of the particular problem was on the day of the crash and the computer was not necessarily updated daily.

I think this crash is one of those perfect examples of Dr Reason's swiss cheese analogy at work. It goes to show that you need a good working knowledge of your systems and not to be distracted in your checks.