Havarikommissionen: Ingen aner, hvorfor IC4-bremserne svigter
more_vert
close

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

close
By signing up, you agree to our Terms & Conditions and agree that Teknologiens Mediehus and the IDA Group may occasionally contact you regarding events, analyzes, news, offers, etc. by telephone, SMS and email. Newsletters and emails from Teknologiens Mediehus may contain marketing from marketing partners.

Havarikommissionen: Ingen aner, hvorfor IC4-bremserne svigter

Det er svært at sige, hvorfor bremserne svigtede på det IC4-tog, der i december sidste år kolliderede med et stillestående tog på Esbjerg Station. Ifølge Havarikommissionen, der har undersøgt hændelsen grundigt, er det faktisk ikke muligt at dokumentere, hvad der ligger til grund for den forringede bremseevne.

»Nej, det kan man ikke dokumentere, og det er også det, vi påpeger i rapporten. Mange har måske deres antagelser, men vi har været inde at tjekke for glatte skinner. Vi har ikke kunnet dokumentere noget unormalt, som ikke skulle være der, og vi har tjekket så godt, som man kan,« siger Bo Haaning, kontorchef i Havarikommissionen.

De to tog stødte sammen, da bremseevnen i det kørende IC4-tog svigtede i en grad, der gjorde, at toget ikke kunne bringes til standsning over en distance på 121,5 meter – selv om det kun kørte 30 km/t. Ifølge Havarikommissionens rapport, der blev offentliggjort for lidt over en uge siden, havde lokomotivføreren ikke oplevet glatte skinner på ruten inden hændelsen. Og som Bo Haaning i dag bekræfter, har kommissionens undersøgelsesarbejde altså ikke kunnet dokumentere glatte skinner.

Læs også: Havarikommission: Hjulblokering bag IC4-sammenstød i Esbjerg

Alligevel har rapporten ikke vakt bekymring hos Trafikstyrelsen, der er statens organ for sikkerhed på jernbaneområdet. Styrelsen meldte efter rapportens udgivelse ud, at den ikke gav anledning til at foretage sig noget nyt, da man har fuld tiltro til, at DSB tager togene ud af drift, hvis de ikke kan bremse.

I 2011 blev alle IC4-togene taget ud af drift, da to tog ikke kunne standse ved et rødt stopsignal. I 2012 udstedte Trafikstyrelsen en midlertidig tilladelse til at tage IC4-togene i brug igen, og sidste år blev tilladelsen permanent, da styrelsen vurderede, at togets bremseevne under normale forhold er fuldt dokumenteret.

Læs også: Trafikstyrelsen: Vi har styr på IC4's bremser

"...da man har fuld tiltro til, at DSB tager togene ud af drift, hvis de ikke kan bremse."

Super, så den dag toget brager ind i evt. et andet tog og flere personer kommer til skade, så tager vi da bare det tog ud af drift!

:/

  • 20
  • 0

I tager alle samme fejl. IC4 er ikke et tog, det er en stopklods. Et togsæt i Esbjerg beviste, at tingesten virker fint som stopklods, men er mindre hensigtsmæssigt som tog.

Et IC4-tog kunne ikke bremse, men den fejl blev straks afbøjet af et andet IC4. Så sig ikke IC4 ikke kan bruges til noget.

  • 10
  • 2

Hvad bygger styrelsens tillid på? Fakta er, at der har været bremseproblemer på IC4. Hverken HK eller DSB er i stand til at komme med en løsning på problemet. Og alligevel triller toget videre. Så hvorfor er det, at
"man har fuld tiltro til, at DSB tager togene ud af drift, hvis de ikke kan bremse"

  • 8
  • 0

klip fra SIN-L

Esbjerg. Rangering
1.
Almindelige bestemmelser
1.1.
Gyldighedsområde
Denne instruks gælder for Esbjerg station.
1.2.
Hastighed
Højst tilladte hastighed er 20 km/t. Ved rangering mod sporstopperne
i spor 0, 1 og 2 er højst tilladte hastighed 15 km/t.

-- Behøver man at sige mere --

  • 2
  • 0

Alligevel har rapporten ikke vakt bekymring hos Trafikstyrelsen, der er statens organ for sikkerhed på jernbaneområdet. Styrelsen meldte efter rapportens udgivelse ud, at den ikke gav anledning til at foretage sig noget nyt, da man har fuld tiltro til, at DSB tager togene ud af drift, hvis de ikke kan bremse.

Man har forsøgt at genskabe de forhold under hvilke fejlen optrådte uden at kunne reproducere fejlen.

Ikke-reproducerbare fejl er typiske for real-time software.

Real-time software fejl, hvis de eksisterer, vil potentielt optræde alle steder det pågældende software er installeret, in casu på samtlige IC4'er.

Jeg skal ikke gøre mig klog på det eventuelt ansvarspådragende i hvilke handlinger man måtte foretage sig eller ikke i lyset af den oplysning, lad advokater gøre det.

  • 1
  • 0

-- Behøver man at sige mere --

Tjooh..
Man kunne starte med at spørge hvornår den hastighedsgrænse er indført.

Dernæst kan man spørge i hvilket område det gælder? Når man bremser 121 meter væk, er man så i gang med at rangere, eller gør man det i forventning om at være <20 km/t når man når rangerområdet?

  • 0
  • 0

Ikke nødvendigvis forkert, men......
BaneDanmark har en besynderlig form for vedligehold af sidespor og lign. at det næsten er rutine at aflåse sporskifter og/eller sætte hastigheden ned til det rene ingenting.
Mig bekendt er hastigheden ikke litrabestemt, men gælder også for tog, som normalt godt kan bremse (MR, MF).

Man kunne også vende spørgsmålet lidt:
Er der nogen som ved hvorfor det faktisk lykkes nogle gange for IC4 at bremse?

Men ja, IC4 egner sig bedst som en art sporstopper eller rullende sporspærring.

  • 3
  • 0

Da man ikke har kunnet finde årsagen, betragtes det som sikkert nok at køre videre?
Jeg tænker på hvad man havde gjort hvis man kunne finde årsagen. Havde man så grounded alle IC4 indtil det var korrigeret.
Fra mobiltelefoner har jeg selv været involveret i disse irriterende sporadiske fejl. Sommetider er det omgivende netværk indblandet, hvor IC4 trods alt ikke har de samme usikkerheder og ukendte.
En mobiltelefon er sjældent sikkerhedskritisk, så sommetider fandt vi fejlen, men det skete også, at årsagen aldrig blev fundet inden modellen gik ud.
At man ikke, efter de første hændelser, har prøvet finde fejlen ved hjælp af uafhængige sensorer og logning undrer mig, da det trods alt er sikkerhedskritisk, og togets egen logning åbenbart ikke er meget værd, da den baserer sig på den samme fejlende software/hardware.

  • 3
  • 0

http://www.dr.dk/tv/se/gintberg-pa-kanten/...

Tror billedet på forsiden er Jan Gintbergs ansigtsudtryk da lokoføreren ikke kan svare på spørgsmålet: "Hvis du klodsede bremserne nu, hvor længe ville du så være om at bremse?" [13:36] Ender med at svare at "det er et godt spørgsmål".

Højdepunkter, selv om jeg og familien grinede af det meste:
[4:30]
CFG: Change For Good
[4:50]
Carsten Hofmeister: "Til at starte med var der vel 700"....
JG: "Altså 700 varige ændringer på hvert IC4 tog som kommer ind direkte fra fabrikken i Italien. Jeg ved ikke om det er derfor det hedder IC4, fordi der kun er 4 ting der virker?"
...
"Man har indtryk af det er en Polterabend der bare er gået lidt over gevind..."

[5:35] CH: "Det er sådan, at når vi får et tog fra Italien af, så går vi fluks igang med at bygge toget færdig, lave en masse ændringer. Og der er vores italienske kollegaer sommetider haft det lidt svært ved at skaffe reservedele både til dem men absolut også til os. Så derfor er vi så gået over og lånt lidt reservedele fra nogle af de toge, indtil de så er kommet fra vores leverandører ik'å"
JG: "Fordi der mangler reservedele så tar' man dem ud af helt nye IC4 tog og sætter dem over i de IC4 tog som rent faktisk kører! - Det er DSB's svar på organ donation, simpelthen ikk altså! Der sidder hjertelæger på Rigshospitalet sådan her (ryster på hovedet) 'I er jo fandme ikke rigtig kloge altså'".

Absolut anbefalingsværdigt at se, hvis man ellers er til Jan Gintberg.

  • 1
  • 0

det pågældende italienerskrammel blev indrangeret (efter SR §46) på Esbjerg station.

At det hedder "indrangering" indbyder til misforståelser om at der er tale om rangering. Dette er ikke tilfældet, og derfor kan reglerne om rangering heller ikke anvendes i tilfældet i Esbjerg. Nedenfor er angivet lidt pluk fra Banedanmarks SR:

Ind- ud- og forbirangeringer anvendes når almindelig signalgivning ikke kan eller må anvendes (SR §46 og 47).

SR §46, 1. Almindelige bestemmelser:
Hvis der ikke kan eller må anvendes signalgivning for ind-, ud- eller
gennemkørsel, og signal ”Stop og ryk frem” heller ikke kan
anvendes, skal togene føres ind på eller ud af stationen ved
tilladelse til lokomotivføreren til
- indrangering
- udrangering
- skriftlig udkørselstilladelse.

SR §46, 6. Kørsel på sigt
Lokomotivføreren skal køre på sigt
- ind på stationen, når der gives toget tilladelse til indrangering
- ud af stationen, når der gives toget tilladelse til udrangering.

SR §2, 5.2. Kørsel på sigt
Kørsel med højst 40 km/t.
Lokomotivføreren skal være forberedt på at
- møde en hindring
- traktorvejssignaler, varslingsanlæg og anlæg for automatisk sikrede
overkørsler ikke kan påregnes at virke.
Et slukket uordenssignal giver ikke garanti for, at en overkørsel er
sikret.

Det er endvidere fornuftigt beskrevet i SR information 2/2009 at ind- og udrangering er ikke rangering;

...og ind- og udrangering er ikke rangering
Selvom ordet »rangering« indgår i både »indrangering« og »udrangering«, er der ikke tale om rangering efter § 36. Den væsentligste forskel ligger i ansvarsfordelingen mellem stationsbestyreren og lokomotivføreren.
Ved ind- og udrangering er det i § 46, punkt 7 foreskrevet, at stationsbestyreren skal foretage togvejseftersyn, og det er dermed som udgangspunkt hans ansvar, at sporet er frit, og at de nødvendige sporskifter er retstillede, har kontrol og er sikret mod omstilling, når tilladelse til ind- eller udrangering gives.
Reelt et det de samme betingelser som ved signalgivning - altså togkørsel. Dog med visse undtagelser, fordi der logisk nok ikke altid kan opnås den fornødne sikkerhed til signalgivning. Ellers
ville ind/udrangeringen jo ikke være nødvendig. Det er imidlertid også foreskrevet, at lokomotivføreren skal køre på sigt under en ind- eller udrangering. Dette skyldes naturligvis, at sikringsanlægget normalt ikke vil give den optimale sikkerhed for, at forholdene til stadighed er i orden.
En anden grund til at holde ind- og udrangering skarpt adskilt fra rangering, er at der ved ind- og udrangering ligger en »indbygget« tilladelse til at passere alle signaler på vej ind på eller ud af statio-
nen, i modsætning til, hvis der er tale om rangering efter § 36. Her er det er krævet, at hvert enkelt signal, der skal passeres, uden at det viser en kørtilladelse, direkte skal nævnes i tilladelsen.

Med venlig hilsen
/Jens

  • 1
  • 0

Hvorfor kan I ikke værdsætte det fuldautomatiske system DSB har skabt. Hvis bremserne virker, så kører toget som det skal (bortset fra koblingsproblemerne). Og hvis bremserne holder op med at virke, ja så går der ikke ret længe før toget sætter sig selv ud af drift. Det er da smart!

  • 0
  • 0

Når ingen nu vil sige, toget duer ikke, kan det vel ikke være fordi, der er et vist pres for at toget skal køre?

På den anden side - hvis nu IC4 en gang til skaber overskrifter, ja så er der vel en kommission og en styrelse, som må tage ansvaret.

Mangler vi den lille dreng fra "Kejserens nye klæder"?

  • 0
  • 0

HCLJ-konklusionen virker tam, gentager Marslev observationerne og tilføjer:

"Havarikommissionen konkluderer desuden på baggrund af hændelserne i Esbjerg, at den manglende bremseevne kan optræde uafhængigt af hastigheden."

Lidt graven i Nordamerikanske og Europæiske jernbaners skriv om nedbremsning af tog kunne ellers for flere år siden have henledt opmærksomheden på problemet og hvad man gør ude i verden. De afledte rigide regler, som findes rundt omkring, for beregning af maximal standselænge (minimal headway length) ligeså.

Årsagen til bremsernes uforudsigelighed skal formentlig søges i manglende viden hos de oprindelige bremsesoftwareprogrammører. Derfor har det sikkert ikke været muligt at skrive en brugbar instruks i bremsernes anvendelse. Deja vu! Den "feature", som løsner bremsen, når toget står stille skal naturligvis ikke gøre det før alle aksler og hele toget står HELT stille.

HCLJ's anbefaling efter Marslev var at alle aksler altid skulle bremse lige kraftigt, men der er heldigvis endnu intet, der tyder på, at denne katastrofale anbefaling er blevet fulgt.

Men bare for sikkerheds skyld: husk altid låg på varm kaffe i toget eller bussen.

  • 0
  • 1

Årsagen til bremsernes uforudsigelighed skal formentlig søges i manglende viden hos de oprindelige bremsesoftwareprogrammører. Derfor har det sikkert ikke været muligt at skrive en brugbar instruks i bremsernes anvendelse


Det behøver du ikke antage. Problemet er at hele området real time programmering er teoretisk umodent. Nu er min viden på området ikke den nyeste, men såvidt jeg kan opdatere mig til er der to generelle tilgange til problemet dataintegritet in real time systemer:

a.
http://en.wikipedia.org/wiki/Lock_(compute...
citat:
http://en.wikipedia.org/wiki/Lock_(compute...
'Lock-based resource protection and thread/process synchronization have many disadvantages:

  • They cause blocking, which means some threads/processes have to wait until a lock (or a whole set of locks) is released. If one of the threads holding a lock dies, stalls/blocks or goes into any sort of infinite loop, other threads waiting for the lock may wait forever.

  • Lock handling adds overhead for each access to a resource, even when the chances for collision are very rare. (However, any chance for such collisions is a race condition.)

  • Locks can be vulnerable to failures and faults that are often very subtle and may be difficult to reproduce reliably. One example is the deadlock, where (at least) two threads each hold a lock that the other thread holds and will not give up until it has acquired the other lock.

  • Lock contention limits scalability and adds complexity.

  • Balances between lock overhead and contention can be unique to given problem domains (applications) as well as sensitive to design, implementation, and even low-level system architectural changes. These balances may change over the life cycle of any given application/implementation and may entail tremendous changes to update (re-balance).

  • Locks are only composable (e.g., managing multiple concurrent locks in order to atomically delete Item X from Table A and insert X into Table B) with relatively elaborate (overhead) software support and perfect adherence by applications programming to rigorous conventions.

  • Priority inversion. A low-priority thread/process holding a common lock can prevent high-priority threads/processes from proceeding. Priority ceiling protocol can be used to prevent priority inversion. Priority inheritance can be used to minimize priority-inversion duration.

  • Convoying. All other threads have to wait, if a thread holding a lock is descheduled due to a time-slice interrupt or page fault (See lock convoy)

  • Hard to debug: Bugs associated with locks are time dependent. They are extremely hard to replicate.

It's possible to use a concurrency control strategy that doesn't have some or all of these problems. For example, using a funnel or serializing tokens can make software immune to the biggest problem: deadlocks. Alternatively, it's possible to avoid locks entirely using non-blocking synchronization methods, like lock-free programming techniques and transactional memory. However, these alternative methods often require that the actual lock mechanisms be implemented at a more fundamental level of the operating software. Therefore, they may only relieve the application level from the details of implementing locks, with the problems listed above still needing to be dealt with beneath the application.'

b.
http://en.wikipedia.org/wiki/Software_tran...
som bare findes i eksperimentelle implementationer.

  • 0
  • 0

Mange tak for bidraget, Torsten. Jeg genkender lidt af et nutidigt pensum i parallelprogrammering.

Min hentydning til indlæggets overskrift gik kun på at denne type problemer ikke er ukendt andre steder i verden. Men der kan være meget langt fra en forståelse af et problem til en løsning af det, som lader sig formidle.

Den workaround DSB har fundet på vil i fremtiden kunne sikre, at der ikke holder et tredje togsæt på et ankomstspor. Indtil softwaren er blevet opdateret om et halvt års tid +/- 3 måneder, skulle man nok kunne leve det.

  • 0
  • 0