-
Det kan meget vel være at man i forbindelse med undersøgelsen har fundet ud af at der var virus i en jord baseret computer hos Spanair.
Jeg har bare enddog meget svært ved at se hvordan det skulle have haft indflydelse på ulykken.
Det var det system der var ansvarlig for at sammenholde løste og uløste fejlrapporter og da flyet allerede havde to udestående uløste fejlrapporter skulle det ikke have haft lov til at flyve.
Fordi computeren brugte det meste af sin energi på malware, blev data ikke behandlet og flyet ikke holdt på jorden.
Og ja, det er en mere end trist historie.
http://blog.seattlepi.com/aero....asp
Poul-Henning
Det må så have været Spanairs datasystem for log og vedligeholdelse som kan have været påvirket.
Men det er altså ikke i stand til at få et fly til at falde ud af himlen som det fremstilles i artiklen ovenfor:
''Det betød ifølge TechnewsDaily, at computeren ikke forhindrede flyet i at lette, selvom det ulykkesramte fly havde tre fejl og derfor ikke burde få tilladelse til at gå på vingerne. ''
For dette system kan ikke forhindre noget fly i at lette.
Der ud over noteres det at fejlen som fik flyet til at vende om lige inden styrtet var den tredje fejl på systemet på få dage.
Mange selskaber har et system for opfølgning af gentagne fejl.
Men.
1: For det første ville en evt advarsel ikke poppe op i selve flyet.
Det ville komme ud som en melding til selskabets troubleshootingafdeling som sandsynligvis ville skrive en arbejdsbeskrivelse for troubleshooting ved et snarligt natstop (minimum inden for MEL perioden).
2: Da det jo var den 'tredje' fejl som fik flyet til at vende om og mekanikeren til at release flyet på MEL så ville den alligevel ikke poppe op hos troubleshooterne før han læste logsekvensen ind datasystemet. Det er der ingen regler om skal ske inden afgang.
Denne virus, hvis det er som beskrevet, kan IKKE få flyet til at falde ned.
Det kan højst være en note i den endelige rapport.
Vi har netop diskuteret denne ulykke på et human factor kursus jeg har deltaget i.
Det som er det mest ulykkelige i denne sag er det klassiske sammenfald mellem flere faktorer som i sammenhæng skaber en ulykke.
1: Flyet returnerer til rampen med en melding om at der er varme på RAT proben (Ram Air Temp). Denne probe skal ikke kunne varme på jorden.
(Den går nemlig over flyets air/ground logik).
2: En RAT probe med varme på jorden kan meget sandsynligt betyde at et ground kontrol relæ er gået i stykker. (I dette tilfælde fejlet i 'air' mode).
3: Takeoff warningen går over samme ground control relæ. (Og Take-off warningen skal ikke kunne fungere i luften).
4: Da piloterne er stoppet midt i deres checkliste ved den første afgang (fra hvilken de returnerede til rampen) og med den stress som opstår (missede slot tider osv), så sker der sandsynligt det at de ikke får kørt deres checkliste igen (human factor).
5: Derfor (fordi den ene halvdel af flyet 'tror' det er i luften) kommer der ikke nogen takeoff warning da de skubber throttlerne frem.
6: Teknikeren releasede flyet med det han troede var en fejl på RAT proben.
Men det han så (at den var varm) var bare et symptom på at halvdelen af flyets systemer var i luften pga det fejlede ground control relay.(Endnu en human factor).
Set i det ulideligt klare bakspejl burde teknikeren selvfølgelig have konsulteret manualerne og specielt en schematic som på et par minutter kunne have fået en klokke til at ringe hos ham.
Der ud over er den anden alvorlige fejl som sagt at piloterne misser checklisten ved deres anden takeoff. Den fejl var 'last line of defense', og den lærer de desværre aldrig noget af.
En af de actions som alle MD80 operatører har indført allerede kort efter ulykken er at takeoff config warning systemet checkes før HVER afgang og ikke som tidligere ved dagens første flyvning og derefter ved crew skift.
Et takeoff config check som ikke giver 'lyd' er nemlig en god indikation på at et ground control relæ er fejlet og det forhindrer netop denne ulykke i at ske igen..
