Ekspert efter IC4-høring: Frygter for fatal fejl i kørecomputeren
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Teknologiens Mediehus kan findes markedsføring fra samarbejdspartnere.

Ekspert efter IC4-høring: Frygter for fatal fejl i kørecomputeren

Transportudvalget var i dag samlet til en høring om IC4-toget fremtid, hvor blandt andet konsulentfirmaet Atkins var til stede.

Høringen forløb en smule anderledes, end sådan nogle normalt gør, fordi trafikordfører Henning Hyllested (EL) overlod sin spørgetid til it-ekspert og lektor ved Datalogisk Institut ved Københavns universitet, Erik Frøkjær, samt Poul-Henning Kamp, der er både it-ekspert og blogger her på ing.dk.

Læs også: IC4, endelig nogle svar

Begge har været skarpe kritikere af Atkins-rapporten, der konkluderer, at IC4-toget grundlæggende er et sundt tog.

Erik Frøkjær hæftede sig især ved, at togets kørecomputer, den såkaldte TCMS-computer, melder en række fejl som hverken Atkins eller DSB har været i stand til at afkode.

Adspurgt om netop, hvordan Atkins kan konkludere, at systemerne grundlæggede er sunde, svarede mekanisk ingeniør hos Atkins Keith Paling.

»Jeg har oplevet, at hele motorer skulle skiftes ud på tog i Storbritannien. Hvis der ikke skal foretages store ændringer, er systemerne generelt sunde. De fejltyper der blev fundet på systemet og udstyret er typiske ud fra erfaringer fra nye flåder af tog,« svarede han og lagde ikke skjul på, at der vil dukke flere fejl op i løbet af IC4-togenes levetid.

»Det er uundgåeligt. I lighed med alle andre tog. Udfordringerne for ingeniører er at løse de problemer og sikre togenes pålidelighed,« sagde Keith Paling.

Han understregede, at Atkins i sin rapport rangerer togets kørecomputer som nr. fire på listen over systemer, der generer fejl og forårsager forsinkelser på fem minutter eller mere.

De fleste fejl er falske

Men, han pegede også på, at undersøgelser viser, at de fleste fejl er falske eller fejlagtigt klassificeret.

Derfor arbejder DSB på at filtrere de falske alarmer 'fra'.

Men netop den del får det til at løbe koldt ned af ryggen på it-ekspert Erik Frøkjær, og det lagde han heller ikke skjul på hverken under eller efter høringen.

Problemet i hans optik er, at DSB ud fra empiriske oplevelser filtrerer fejlmeddelelser fra, som man mener, optræder fejlagtigt.

»Med sin computer derhjemme kan man ignore fejl, hvis man ikke forstår dem, og den ellers virker, men det kan man ikke med sikkerhedskritiske komponenter,« siger Erik Frøkjær.

Han peger på, at ingen endnu kan forklare, hvorfor IC4-togets bremser svigter på et meget glat underlag.

Han frygter, at en periodisk systemfejl kan være skyld i bremseproblemerne. Og den fejl kan ikke genskabes ved almindelige tests.

Det kræver, at man kigger hele computersystemet igennem.

»Atkins peger på, at man renser ud i fejl, uden at have en grundlæggende forståelse for, hvorfor de opstår. Det er tvingende nødvendigt at få lavet en tilbundsgående og uafhængig undersøgelse af computersystemet, for det er dét, der gør os bange. Hvis de ansvarlige for IC4 i Transportministeriet, Trafikstyrelsen og DSB ser fejlene overhøring, ser jeg det ansvarspådragende, hvis der sker en fatal ulykke. Jeg er frygtelig nervøs,« sagde Erik Frøkjær under høringen.

Under høringen kom det også frem, at Atkins ikke har talt med overingeniør Finn Nielsen, der er uddannet svagstrømsingeniør og systemintegrator på IC4-projektet.

Han blev allerede i 2003 nervøs for projektet, og nervøsiteten tog til, da det gik op for ham, hvordan de italienske konstruktører stolede på, at tingene nok skulle spille sammen ved hjælp af softwarejusteringer.

Poul-Henning Kamp spurgte Atkins direkte under høringen, hvorfor de ikke havde talt med Finn Jensen, 'når I siger, at I har undersøgt TCMS'.

Afdelingsleder i Atkins Danmark og tidligere leder af Havarikommissionen, Johan Stranddorf, svarede, at Atkins også 'havde talt meget med Finn Jensen', men det blev hurtigt ændret til, at 'det er muligt, vi ikke har talt med Finn Jensen', efter det blev påpeget, at Finn Jensen ikke fremgår af Atkins' mødelister.

Der har tidligere i Ingeniøren været rejst kritik af Atkins' undersøgelser af togcomputeren, men Atkins har også tidligere afvist kritikken.

Læs lektor Erik Frøkjærs notater til IC4-høringen
[scribd:81061867]

sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Skal det forståes sådan at Johan Strandorff både er lønnet af Atkins og af Havarikommisonen ??

Hvis det hænger sådan sammen ? -, hvordan kan han så overhovedet udtale som om IC4, et tog som hans ene arbejdsgiver har kaldt 'grundliggende sundt' og som hans anden arbejdsgiver er ved at havariundersøge som følge af en kritiske fejl.

  • 0
  • 0

Der skulle have stået, at Johan Stranddorf er tidligere formand for Havarikommissionen. Det er rettet nu. Beklager forvirringen.

Mvh.

Kasper Brøndgaard Andersen, journalist
Ingeniøren

  • 0
  • 0

der kan siges med sikkerhed om teknikken i disse tog.
Hvor hurtigt skulle disse tog køre? Selv med 10 km/h vil de kunne lave store ulykker.

Er der en teknikker til stede?

  • 0
  • 0

Som en seriøs IT professionel er det totalt uansvarligt at foreslå at man løser kørecomputerens problemer ved at frasortere fejl. Det ville svare til at man går til lægen og får symptombehandling for en hovedpine uden en undersøgelse, det kan være at man har migræne det kan også være at man har en tumor i hjernen, men fordi undersøgelsen ikke bliver lavet kan man ikke konkludere nogle af delene.

Faren ved denne tilgang til sagerne er at man kan komme til at frasortere fejl der dybest set var reelle nok men kun i tilfælde som man endnu ikke har forstået (som fx hvorfor kan toget ikke finde ud af at bremse). Hvis der er fejl i systemet der direkte er ubrugelige af den ene eller anden grund, skal de selvfølgelig ikke være der, men det løses ved at de fjernes i softwaren der fra hvor de opstår og ikke der hvor der skal tages stilling til dem.

For en der har siddet med meget fejlfinding er det mig totalt uforståeligt hvordan de kan konkludere at computeren er rask hvis de ikke ved hvad det er den melder tilbage.

  • 0
  • 0

Som en seriøs IT professionel er det totalt uansvarligt at foreslå at man løser kørecomputerens problemer ved at frasortere fejl....

Fuldstændig enig. Det er så amatøragtigt, at man ikke ved om man skal græde eller grine; men da den farce koster samfundet flere hundrede millioner kr., vælger jeg nok det første.

Fejl skal afhjælpes ved kilden, og fejl fra systemer, som ikke bruges eller virker, skal frakobles.

  • 0
  • 0

Frasortering af fejl kan være aldeles okay, fordi vi ingeniører nogle gange er alt for glade for de tilbagemeldinger vi kan uddrage af hardware, og synes de er yderst relevante. Især når man stadig udvikler systemet.

Samme oplevelse behøver brugerne ikke at have.

Brugerne skal kun have de kritiske fejl op - ikke alle mulige ligegyldige fejl. Erfaring siger at brugerne til sidst overser, ignorer fejl eller mistolker fejlen som ubetydelig (de 100 før var jo det).

Så hellere frasortere så kun de væsentligste fejl kommer til brugernes opmærksomhed. Log resten for teknikerne til løbende opfølgning, da mængden af frasorterede fejl kan sige noget om systemet sundhed.

  • 0
  • 0

Så hellere frasortere så kun de væsentligste fejl kommer til brugernes opmærksomhed.

Denne frasortering er allerede sket.

Det man gør nu, er at lappe over systemets upålidelighed og uforudsigelighed, ved at undertrykke indikationerne derpå.

Det er ikke ok.

  • 0
  • 0

Brugerne skal kun have de kritiske fejl op - ikke alle mulige ligegyldige fejl.

Hvilke detekterede fejl mener du, er ligegyldige? Nævn bare én.

Jeg har aldrig oplevet et proceskontrolsystem, hvor en fejl ikke har én eller anden konsekvens. Det er jo lige netop derfor man har lavet en fejlovervågning! Ligegyldige ting overvåges ikke og giver derfor ikke anledning til fejl.

Det er skandaløst, at man som ved Atkins test af sammenkoblingen kan få fejl, som ingen kan overskue eller aner, hvorfra de kommer.

  • 0
  • 0

være konsekvenser af så lemfældig omgang med borgernes penge... Er rystet over at mennesker med så meget ansvar, kan tage så mange dårlige beslutninger i træk. Hvordan i alverden er de overhovedet kommet i betragtning til jobbet? Der må da være nogen der har lavet en udførlig kravpecifikation inden de er taget til Italien med containerfuld kontanter...

  • 0
  • 0

Jeg har ikke arbejdet med IC4 tog eller noget andet tog. Jeg har arbejdet i Atkins for 5 år siden, men kender overhovdet ikke noget til deres rapport eller hvad de skriver herom. Så jeg finder anklagen ret stødende. Jeg forholder mig ikke til rapporten, men det overordnede om kan tillade sig at frasortere fejl eller ej. Jeg synes man skal forholde sig til budskabet.

Min erfaring med digitale systemer er, at man kan få ligegyldige fejl. Det kan være fra datastorm, sløjfebrud, hvor backup sløjfen med det samme samler systemet på, men alle overvågede komponenter var et ½ sekund ude af kontrol pga. mangelende kommuniktation. Så her kan man få fejl fra hver eneste enhed.

Her kan det være formålstjenesteligt at frasortere alle fejl undtagen sløjfebruddet, da det er hovedfejlen resten var bare følgefejl.

Er det ideelt nej. Skulle man have tænkt det ind i designet ja.

Vi oplever det i masser af systemer i dagligdagen. Bilen, vaskemaskinen osv. her er der masser af målinger og fejl som kun en tekniker via en log PC har adgang til. Vi får kun nogle få overordnende indikeringer.

  • 0
  • 0

Her kan det være formålstjenesteligt at frasortere alle fejl undtagen sløjfebruddet, da det er hovedfejlen resten var bare følgefejl.

  1. Det har man forhåbentlig allerede gjort i TCMS.

  2. Det lød bestemt ikke som det man var ved at implementere.

  3. Men hvordan kan nogen vide hvad der foregår, når selv ikke Atkins med Folketingets mandat kan få lov til at tale med folk med forstand på tingene i DSB ?

  • 0
  • 0
  1. Måske. Har ikke kendskab til designet. Men overrasker mig ikke at der kan komme mange falske fejl, især hvis systemet er dårligt programmeret, hvilket noget kunne tyde på her.

  2. Det er ikke til at vide. Jeg antager at togcomputeren som alle sikkerhdssystemer skal sikkerhedsgodkendes. Så der er forhåbentligt nogen som kigger på filteret, og sikrer, at der ikke fjernes kritske fejl der skulle være kommet til brugerens opmærksomhed.

  3. Det må du spørge transportministeren om. Han bestemmer både over DSB og den opgave Atkins har fået.

  • 0
  • 0

Med reference til hændelsen på kernekraftværket på Three Mile Island i 1979 var en af faktorerne til at hændelsen voksede til et uheld at der kom over 100 alarmer i de første stadier og at det ikke var muligt at afbryde de uvæsentlige og identificere de vigtige. (kommissionsrapportens konklusion A.8.b). Dette understreger at der i systemer med overvågning af mange tilstande og parametre er et behov for filtrering af disse, så operatøren (her lokomotivføreren) kan vurdere om det er forsvarligt at fortsætte kørslen med toget.

Moderne tog er i øvrigt ofte udstyret med log udstyr der opsamler data og transmitterer disse til en central server, som gør disse data tilgængelige for vedligehold. Om IC4 er udstyret med en sådan facilitet ved jeg ikke.

  • 0
  • 0

Moderne tog er i øvrigt ofte udstyret med log udstyr der opsamler data og transmitterer disse til en central server, som gør disse data tilgængelige for vedligehold. Om IC4 er udstyret med en sådan facilitet ved jeg ikke.

Det er IC4. Det tager en tekniker 4 timer at grave sig igennem 10.000 linier der typisk dækker 7-10 dages kørsel.

Mit gæt: Det præsenteres i et regneark.

  • 0
  • 0

Poul-Henning Kamp
Re: Filtrering af alarmer (I bliver vist ..)[/quote]

Så må vi håbe at der er en dygtig Excel operatør der kan automatisere sortering i 'bunken'. Jeg har selv prøvet noget sådant for en del år siden da jeg søgte fejl i et kommunikationssystem. Det viste sig at en komponent, der ikke blev udskiftet iht forskriften for vedligehold, var den bagvedliggende årsag, hvilket holdt mig og andre beskæftiget i flere måneder. Vi havde ca. 250 linjer/døgn når der var flest, så det var nemmere at overskue.

  • 0
  • 0

Kaster lige en boldt op her.
Som tildliger medarbejder hos flextronik.
oplevede man fejlkomponenter på printplader til div elektronik mainbords m.m
Kunne skaden ikke rettes kasserede man disse.
Alternativt hvis der øjensynligt var et komponent der ikke normaltvis tillægges stor betydning kunne man ændre lidt på firmware i ic kredsene.

Hvilket i dette tilfælde også kunne være medvirkende årsag.

I dette tilfælde kan man kigge længe i logfiler.
Kombiner dette med dårlig programmering.... Ja så tager jeg heller bilen.

  • 0
  • 0

kører nødbremsen igennen computeren?

Det sikre vil jo være at den bypasser computeren, så man har bedre sikkerhed for at bremsen virker som i gammeldags tog.

  • 0
  • 0