Uheldsramt IC4 bremsede perfekt i dagens test

Bremseeksperter fra tyske DB Systemtechnik og den franske bremseproducent Faiveley var fredag eftermiddag vidne til to vellykkede test af bremsesystemerne på IC4-togsæt 5627 - det togsæt, der 7. november var impliceret i en alvorlig nærved-ulykke på Østfyn.

Under den bremsetest, som Ingeniøren deltog i, blev der foretaget såkaldt farebremsning fra hhv. 160 og 180 km/h. I begge tilfælde med den forventede og reglementerede bremselængde.

Ifølge koncerndirektør i DSB Frank Olesen havde togsæt 5627 indtil hændelsen 7. november aldrig haft problemer med bremserne. Togsættet blev indsat i drift i foråret og havde indtil nærved-ulykken kørt 80.000 kilometer med passagerer.

Læs også: Tidslinje: Følg IC4-købet fra 2000 til i dag

Ifølge souschef og havariinspektør i Havarikommissionen Bo Haaning har kommissionens arbejde endnu ikke afdækket uregelmæssigheder ved togsæt 5627.

»Vi arbejder med flere forskellige hypoteser for, hvad der kan have forårsaget hændelsen på Østfyn. Men ingen af dem er blevet bekræftet gennem de foreløbige undersøgelser. Vi vil være klogere i næste uge, når vi har afsluttet weekendens mange testkørsler, hvor bremserne skal testes under forskellige forhold,« siger han.

Den test, som pressen var inviteret med på, foregik på en strækning med gode, tørre skinner og med togets såkaldte magnetskinnebremse indkoblet. Dermed var der bestemt ikke tale om forhold, der er sammenlignelige med dem, der gjorde sig gældende den famøse november-eftermiddag med vådt vejr, tåge og meget høj luftfugtighed.

Dertil kommer, at magnetskinnebremsen på togsættet ikke var indkoblet, da nærved-ulykken fandt sted 7. november. Magnetskinnebremsen giver et tillæg til bremsekraften på ca. 20 pct., men det er ikke et sikkerhedskrav, at den skal være indkoblet på IC4-toget.

Det skal kunne bremse sikkerhedsmæssigt forsvarligt uden brug af magnetskinnebremsen, som er en slags nødbremse, der ikke benyttes under normal drift, men som fungerer ved, at et magnet sænkes ned på skinnens overflade og aktiveres, hvorved friktionen skaber bremseeffekt.

*Er det fortsat en mulighed, at samtlige systemer på togsæt 5627 fungerer upåklageligt, og at der ganske enkelt er tale om et sammenfald af uheldige vejr-forhold og glatte skinner kombineret med, at nødbremsen/magnetskinnebremsen var ude af drift? *

»Den mulighed kan fortsat ikke udelukkes,« siger Bo Haaning, der ikke ønsker at gå yderligere i detaljer med de hypoteser, som Havarikommissionen arbejder med.

I løbet af weekenden vil togsættet blive testet på glatte skinner og med magnetskinnebremsen udkoblet. En særlig sæbeblanding - opbevaret i en industritank om bord på toget - vil fra dyser på togets front blive sprøjtet ud på skinnerne for at gøre dem glatte og dermed skabe sammenlignelige forhold i forhold til hændelsen 7. november.

Eksperterne fra DB Systemtechnik, Faiveley, Ansaldobreda og DSB var under testen travlt beskæftiget med at overvåge de sensor-systemer, som eksperterne havde installeret på bremsesystem og powerpacks. Efterfølgende skal eksperterne gennemlæse de relevante computerlogs for at finde eventuelle uregelmæssigheder. Det var ikke muligt for Ingeniøren at få indsigt i resultaterne af disse test efter testkørslen.

Før og efter testkørslen blev der foretaget undersøgelse og opmåling af togsættets hjulflader. Det sker for at blive klogere på, hvordan de enkelte hjul bliver påvirket af nedbremsningen. Det er et nøglepunkt i efterforskningen at undersøge, om IC4-togets hjul i større eller mindre grad foretager utilsigtede blokeringer under en hård nedbremsning, og om togets antiblokeringssystem (WSP) fungerer tilfredsstillende.

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

... er det præcis det resultat man kan forvente af en test.

1: Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... BANG!!!

Hov? Vi må hellere teste igen (goto 1:)

Det er bare fast arbejde.

  • 0
  • 0

Hvorfor har de ændret togets konfiguration inden de kørte testkørslen? Så giver det da god mening at toget opfører sig anderledes i forhold til sidst.

  • 0
  • 0

Hvorfor har de ændret togets konfiguration inden de kørte testkørslen? Så giver det da god mening at toget opfører sig anderledes i forhold til sidst.

Hvis de har en systematisk log over de ændringer du foretog, så kan de nu arbejde sig baglæns hen til den tilstand, hvor bremsningen var meget dårligere end forventet

»Vi arbejder med flere forskellige hypoteser for, hvad der kan have forårsaget hændelsen på Østfyn. Men ingen af dem er blevet bekræftet gennem de foreløbige undersøgelser. Vi vil være klogere i næste uge, når vi har afsluttet weekendens mange testkørsler, hvor bremserne skal testes under forskellige forhold,« siger han.

Lad os håbe at de husker at prøvekøre toget med en del bogier, der var sat til ledning, så togets bremseprocent var mindre end ab fabrik

  • 0
  • 0

...mere i de ikke-tog? Skrot IC4 nu og kom igang med elektrificering.

Måske fordi der står tog svarende til X antal mia og venter på at komme til at køre ?

Ok, hvis du har en personlig formue i samme størrelsesorden du er klar til at smide i puljen, så må du da gerne det, men hvis du ikke har, så ville det klæde dig at lade være med at komme med den slags tåbelige forslag.

M

  • 0
  • 0

... er det præcis det resultat man kan forvente af en test.

1: Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... Det fungerer perfekt... BANG!!!

Hov? Vi må hellere teste igen (goto 1:)

Det er bare fast arbejde.

lad mig gætte for et øjeblik - du har teoretisk viden men har aldrig prøvet at få noget til at fungere i virkeligheden ?

M

  • 0
  • 0

Der er noget der hedder udviklingstid og udgifter. Man er nød til at sætte en grænse for et hvert projekt, for hvor lang tid der må gå og hvor mange penge og arbejdstimer der må bruges. For ikke at risikere at produktet bliver forældet og at der spildes en masse penge uden at man opnår det ønskede resultat. Det kan lyde af mange penge at smide væk ved at skrotte et projekt. Men jo senere man erkender at projektet er løbet af sporet jo mere spilder man. Selv store danske virksomheder har svært ved, at sætte disse grænser. Men staten er den værste til, at opsætte disse grænser. Her ender det altid med at produktet enten ikke lever op til de stillede krav, eller at man kassere på et så sent tidspunkt at der er spildt uanede mængder penge, som så gør at skatten sættes op.

Ved at erkende at IC4 er en fejl, som ikke lever op til de stillede krav og til nutidens teknologi, spare vi en masse penge. Derudover har projektchefen også selv udtalt sig i en artikel at fortsætter man IC4 projektet, vil det give en masse problemer til den dag togene skal skrottes af alders grunde. Og han er vel at mærke for at fortsætte projektet.

Derfor vil det være en fordel for dansk infrastruktur som helhed, at skrotte IC4 og bruge pengene på, at elektrificere jernbanen over de næste 10- 13 år og i mellemtiden købe de Israelske IC3ere, som erstatning for de manglende tog.

Det hedder rettidig omhu!

  • 0
  • 0

[quote]Hvorfor har de ændret togets konfiguration inden de kørte testkørslen? Så giver det da god mening at toget opfører sig anderledes i forhold til sidst.

Hvis de har en systematisk log over de ændringer du foretog, så kan de nu arbejde sig baglæns hen til den tilstand, hvor bremsningen var meget dårligere end forventet[/quote] Godt princip, men hvorfor arbejder de den vej, og ikke fra den anden side? fra den konfiguration som toget havde den uheldsramte dag?

  • 0
  • 0

For ikke at risikere eksperternes liv!

Derudover for at finde ud af hvor mange ting der skal være slået fra før problemerne opstår. For det kan jo være at problemerne allerede opstår langt tidligere i forløbet, end det der blev oplevet den 3 november.

Men i bund og grund lader det til at computeren er problemet, i det den ikke må undersøges af Atkins og Atkins kun måtte lave interview af AB og DSB og ikke selv få et togsæt de kunne lave fejlfinding på!!

  • 0
  • 0

lad mig gætte for et øjeblik - du har teoretisk viden men har aldrig prøvet at få noget til at fungere i virkeligheden ?

Jeg beskrev en kollektiv oplevelse hos et større dansk firma som producerede egen hardware og software, hvor jeg var ansat i firserne.

Før det skrev og implementerede jeg et operativsystem til et 8080-baseret navigationssystem (NAVSTAR), hvor jeg eksperimenterede med implementering af forskellige synkroniseringsprimitiver (plus floating point pakke, plus sqrt og trig funktioner). Mine erfaringer derfra brugte jeg siden i mit speciale fra DIKU, og i en artikel

ref. Process Administration in a High Level Language, Software Practice and Experience, april 1986

Så jeg var noget chokeret over den nonchalante attitude ingeniører lagde for dagen over for programmering af ting der kontrollerede potentielt eksplosive processer ('Deadlock? Men der er jo en reset-knap på den!').

  • 0
  • 0

Forklaring:

Ingeniører bygger ting. Når de er færdige med det tester de tingen mod dens specifikationer, indtil de er rimeligt sikre på at den ikke indeholde fejl.

Her benytter de sig af at deres test-rum er kontinuert. Ting begynder at opføre sig fejlagtigt i 'nærheden af' (efter en eller anden metrik) det sted hvor de fejler. Broer f.eks. knager og bøjer før de bryder sammen (i reglen, med ubehagelige undtagelser).

Realtids software opfører sig ikke sådan. Test-rummet er ikke kontinuert, og der er derfor ikke nogen gradient i det man kan ekstrapolere til katastrofale steder. Buggy software enten fungerer perfekt, eller fejler katastrofalt, og der er i praksis ikke en gang en mulighed for at rekonstruere de betingelser der førte til den katastrofale fejl.

Derfor fører anvendelsen af det der er god ingeniørpraksis til katastrofale resultater når de anvendes på software. Det er, efter mit bedste datalog-skøn, hvad der er sket i IC4-projektet. Folk der er oplært med test-metodikken undervurderer systematisk den tid det vil tage at finde de fejl der, hvis de havde været hardwarefejl, havde taget uger at lokalisere, men som imidlertid, fordi er softwarefejl, tager år at finde. Trial and error, som er sund praksis for at finde hardwarefejl, er en fundamentalt forkert metode for realtime software.

Dertil kommer at fejlene kan være i princippet ikke-lokaliserbare.

Eksempel: Deadlock

To mennesker spiser på restaurant. Den fattige restaurant har kun én gaffel og én kniv, som de to må deles om. de skriver derfor, hver for sig et lille program de skal følge:

Person A: 1: tag gaffel; tag kniv; spis en mundfuld; læg kniv tilbage; læg gaffel tilbage; goto 1;

Person B: 2: tag kniv; tag gaffel; spis en mundfuld; læg gaffel tilbage; læg kniv tilbage; goto 2;

Og de spiser løs. Det går storartet. Indtil pludselig person A tager gaffelen og person B tager kniven. Nu forsøger A at tage kniven og B at tage gaffelen. Men den har den anden! De kan nu blive siddende i princippet til de dør af sult. Det hedder deadlock.

(Oversættelse: Knive og gafler er resourcer som kun kan bruges af én bruger ad gangen. For en proces i et realtime software system kan det for eksempel være en fil eller en sensor eller setpoint.)

Hvor ligger fejlen? Hvilken linje? Og hvordan vil man finde den, med hvilken systematik? Den slags tilstande kan låse ens PC, eller de kan slå folk ihjel, og det ér sket.

Dataloger har heller ikke svaret på hvordan man undgår deadlock og lignende i realtime software. Imidlertid har de den fordel frem for ingeniører og selvlærte at de ved problemet eksisteret.

  • 0
  • 0

Deadlocks var 3. semester stof på mit ingeniør-studie Torsten. Jeg synes du undervurderer og fornærmer ingeniører-standen ved at skyde dem i skoene at de ikke kender til så velkendte problem-stillinger i samtidigheds-kontekst, som f.eks. deadlocks.

I det realtids-kritiske software jeg er med til at skrive, bruger vi ikke deadlocks ;) Control flow grafen skal være acyklisk med grænser på alle løkker. Dvs. ingen blokerende kode! Vi bruger ikke pre-emptive multitasking; kun co-operativ. De mest kritiske moduler bliver model-checket op imod specifikationer oversat til prædikat-logik. Det kan gøre gevaldigt meget for at undgå bugs som f.eks. deadlocks.

Vi har ikke en eneste datalog ansat hos os, vi er bare en flok skide ingeniører. Man kan altså godt arbejde systematisk og anvende formelle metoder selvom man læste ingeniør i stedet for datalogi.

  • 1
  • 0
Bidrag med din viden – log ind og deltag i debatten