Datavirus kan ha bidratt til flyulykke?

[Gjest Egil Johnsen]

Vel siden vi av og til tar med mer eller mindre saklige artikler om flyvninger og ulykker, så har jeg lagt ved denne. Ikke riktig så ille som tabloidpressen, men ikke langt unna. Ble ikke så mye klokere av å lese denne artikkelen.

 

En ting er diskusjonen om MS og virus (som dere kan se i diskusjonstråden relatert til artikkelen). Det andre spørsmålet er hvordan viruset kom inn i den/de gitte maskinene (hvis man forutsetter at det var virus som skyldes at maskinene gikk ned).

 

Da tenker jeg på brannmurer, soner, overvåkning etc. Mange bedrifter slurver med dette, og hvis det er tilfelle at virus danket ut maskinene (det er jo snakk om maskiner som samler inn data fra fly på bakken), så er det jo slurv og rutinesvikt.

 

Det er i alle fall utrolig tragisk at så mange menneskene omkom. Om et virus var medvirkende, så er det første gang (så vidt jeg vet) at ondsinnet kode er medvirkende til tap av så mange liv.

 

Egil Johnsen

[Frank Eid]

Nå burde vel flyet selv kunne si fra om alvorlige problemer.

 

Det faktum at en sentralisert server ikke fungerer i enkelte tidsrom må man regne med. Dette kan skyldes et utall ting som virus, hardware feil, linjebrudd etc.

 

Husk at alt som skulle til for å stoppe alle tog i dette landet for flere timer var en gåen PSU.

 

[Christian Paulsen]

Når slike ulykker etterforskes skal jo alle hullene i osten finnes, selv de perifere. Men heldigvis skal det mer til enn et virus i en sentral datamaskin til for å bringe ned et fly.

 

Det er vel fortsatt en del uklarheter som etterforskes, men det som er sikkert er at det var bra mye annet som gikk galt under denne flighten før de tok av uten flaps, og uten å få noe TOWS varsel.

 

 

[Frank Eid]

Hmm.. ang. manglende TOWS (vagt minne etter en ACI episode) ;

 

Det var jo en ulykke (A320,i Tyskland tror jeg) hvor man i ettertid fant ut at GPWS audio var satt ut av drift (fjerna sikring) pga. innflyvninger ofte ble foretatt med høy hastighet (og således ofte utløste GPWS audio).

 

Primærårsaken denne ulykken var forøvrig at man mente å angi 3.3 grader i descent angle mens systemet oppfatta det som 3300 ft/min. Natt, Lavt skydekke, fjell og manglende GPWS er dårlig combo ved feilinntasting.

 

[Christian Paulsen]

Ja og det er vel noe i den samme retning her også Frank, men det er fortsatt under etterforskning, og jeg husker ikke helt detaljene fra den foreløpige rapporten og er generelt på syltynn is. :grin:

 

Men de hadde jo i alle fall problemer med en sensor (RAT probe) som kom og gikk (overoppheting på bakken). En del av kretsløpet for Probe heat går visstnok via ground/flight bryteren på nesehjul slik at den ikke skal varme/overopphete når flyet er på bakken. Dette styres av et relee som også styrer noen andre ting, deriblandt TOWS-system (for å hindre at man får TOWS-varsel i luften).

 

Men så husker jeg ikke om mistanken går på at det var feil på dette systemet (som både overopphetet RAT-probe og satte TOWS ut av spill fordi "flyet trodde det fløy"), ELLER om vedlikehold fjernet dette releet for å midlertidig løse problemet (ta vekk strøm) til Probe-heat og utilsiktet dermed også slo av TOWS...?

 

Andre får fylle inn her, for jeg er slett ikke sikker.

 

Det er formodentlig disse gjentatte random RAT-heat problemene datamaskinen med virus skulle fanget opp da, hvis det nå stemmer at det finnes et "3 strikes and your out" varselsystem i loggføringen. Jeg trodde forsåvidt dette var å finne i flyets egen logg, men de blir kanskje ikke studert og vurdert på den måten fordi man har et datasystem som varsler?

 

Noen som vet noe mer om dette her, ikke nødvendigvis ulykken konkret, men systemer som automatisk varsler VS logg i flyet?

 

 

[Tor Strengehagen]

Med mine 20 års erfaring med MD80 kan jeg berolige dere med at feilen som medførte at T/O warning ikke virket på ingen måte kan spores til noe som helst datavirus. Reint oppspinn fra en eller annen dust som ønsker å virke important. Feilen som er gjort er ganske åpenbar og skyldes nok manglende systemforståelse, kombinert med manglende bruk av checklist.

[Christian Paulsen]

Jeg lot vær å nevne navn, men jeg håpet du ville komme å kaste litt mer lys over dette Tor.

 

Men du har kanskje lest litt for fort her, det er "ingen" som tror at det var noe virus som skapte feilen, så det er et ikke-tema.

 

Det jeg stiller meg undrende til og håpet du ville si noe mer om var dette:

 

Det er formodentlig disse gjentatte random RAT-heat problemene datamaskinen med virus skulle fanget opp da, hvis det nå stemmer at det finnes et "3 strikes and your out" varselsystem i loggføringen. Jeg trodde forsåvidt dette var å finne i flyets egen logg, men de blir kanskje ikke studert og vurdert på den måten fordi man har et datasystem som varsler?

Har du noe kommentar til det?

 

Og forsåvidt noe som sikkert er enda letter for deg å svare på (siden jeg formoder at første punkt kan variere med selskap og ikke nødvendigvis helt likt som hos dere).

 

Men altså rent teknisk, hva skjedde. Jeg mente det var noe ala dette:

Men de hadde jo i alle fall problemer med en sensor (RAT probe) som kom og gikk (overoppheting på bakken). En del av kretsløpet for Probe heat går visstnok via ground/flight bryteren på nesehjul slik at den ikke skal varme/overopphete når flyet er på bakken. Dette styres av et relee som også styrer noen andre ting, deriblandt TOWS-system (for å hindre at man får TOWS-varsel i luften).

 

Men så husker jeg ikke om mistanken går på at det var feil på dette systemet (som både overopphetet RAT-probe og satte TOWS ut av spill fordi "flyet trodde det fløy"), ELLER om vedlikehold fjernet dette releet for å midlertidig løse problemet (ta vekk strøm) til Probe-heat og utilsiktet dermed også slo av TOWS...?

 

Disse tingene hadde i alle fall jeg satt pris på kommentarer eller rettelser på, fra noen med peiling og innsikt på MD-80, dvs deg.

 

[Tor Strengehagen]

Jeg ville ikke sette meg ned å prøve å forklare dette i detalj. Men du har helt rett i at dette burde ha vært tatt tak i mye før. Det er et pålegg i hvertfall her hjemme om at selskapet skal ha et seriefeil oppfløgings system. Tech og pilot skulle også sett varsellampene der og da ved å lese log.Ved slike feil er det vanlig å sjekke datasystemet for tidligere anmerkninger i samme ATA system.

 

Jo da beskrivelsen av hva som hendte er ganske klar. Men de med erfaring vet at det er Ground shift som styrer heating av RAT. Så det burde ha ringt en bjelle når denne blir varm på bakken. Det var ikke noe galt med RAT, men ground shift. Med andre ord T/O warning trodde flyet var in flight grunnet feil posisjon GND/FLT på et rele og dermed er T/O warning inhibittet. (ikke særlig lurt med T/O warning i flight) Dette burde tekniker ha sett med en gang og ikke bare trukket sikkeringen for RAT og releaced denne på MEL. Han har med andre ord ikke "pinpointed" feilen men tatt en fast en. Han koblet alså ikke ut T/O warning, det hadde ground shift releet som feilet skylden for. RAT har ikke noen egen kontroll av heat det er kun Ground shft som styrer heating on off. Detta gikk fort. Sorry. For Info så er det i MEL 30.8 RAT heating, nå skrevet en Warning om dette.

[Christian Paulsen]

Takk for det Tor. Da var det omtrent som jeg trodde, men du kan jo naturlig nok forklare dette mye mer presist og korrekt enn jeg kan, så det setter jeg pris på. Detaljene rundt "seriefeil oppfølgningssystem", og den eventuelle relevansen av virus i dette systemet (hvis noen) vil formodentlig bli diskutert i den endelige rapporten.

 

Hele denne tragiske ulykken ser forresten ut som et svært godt eksempel på den populære "oste-metaforen" hvor alle omstendighetene tilsammen gjør at oste-hullene havnet på linje. Sannsynligheten for at alle disse problemene og tabbene skulle skje samtidig vil jeg like å tro er ekstremt liten, men denne gangen gjorde det dessverre nettopp det.

 

Kan være enig i at måten nyheten er vinklet virker litt søkt, at noe har "bidratt" gir nok mange inntrykk av de mener det var av "stor betydning" og en mer direkte årsak. Ut fra diskusjoner rundt om kring kan det også se ut som mange oppfatter det som det du svarte på først, og tror at selve flyets systemer kjører Windows-95 med utdatert Norton Antivirus.

[Tor Strengehagen]

Bare sånn for å gjøre ting klart for de som ikke har noen kjenskap til data systemer i fly. I våres system blir ingen oppdateringer gjort via noe som helst nettverk. Oppdateringer blir laget av fabrikant eller Jeppesen. Disse oppdateringer blir ikke sendt via nett men som disketter, PCMCIA eller CD. Oppdatering av EEC (Electronic Engine Control) blir gjort direkte til EEC med dataloader og kabel. GPWS høyde data base blir lastet ved å sette PCMCIA kortet direkte inn i Comp. De fleste andre blir lastet med disketter via flyets egen dataloader i cockpit. Den sitter til høyre for deg hvis du sitter på klapp i cockpit i en 737NG. Det er ikke mulig å sende noen som helst data til flyet eller å koble seg inn i flyets systemer med noen PC som ikke er spesielt konstruert for dette. Det er ingen mulighet til å komunisere til eller fra flyet på internett. Det er kun en data com link på ACARS som går via VHF 3. Dette systemet er ikke koblet opp mot annet en ACMS som kun mottar signaler, er ikke i stand til å komunisere med noe som helst ombord annet en en printer og en MCDU. Med andre ord så er flyet rimelig godt isolert fra datavirus. Det lever nokk sitt egent liv på en helt annen måte en datane på FS.