Seneste signalfejl: Systemet ved ikke, om der er rødt eller grønt
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.

Seneste signalfejl: Systemet ved ikke, om der er rødt eller grønt

Illustration: Steffen Mcghie

Et signalsystems primære opgave er at holde styr på, hvilke strækninger på skinnerne som er ledige, hvilke der er optaget, og hvor togene følgelig sikkert kan køre, eller om de må standse.

Men i enkelte, ekstreme situationer, som Banedanmark har testet, var det ikke tilfældet på den første strækning med det nye, digitale signalsystem ERTMS, der skulle være taget i drift på Sjælland i maj.

Læs også: Så er den gal med togsignalerne igen: Premiere på Sjælland må udskydes

Det var årsagen til, at Banedanmark fredag trak i nødbremsen og sendte leverandøren, den tysk-franske toggigant Alstom, tilbage til kontoret med beskeden: 'Duer ikke'. Samtidig udskød Banedanmark ibrugtagningen af de nye signaler på strækningen mellem Roskilde og Køge til slutningen af året.

Fanget i afsluttende test

Ifølge styrelsens direktør for signalsystemer, Søren Boysen, hverken kunne eller måtte Banedanmark tage systemet i brug. Det lagde nemlig, i de særlige situationer, ansvaret for at overvåge signalerne over på trafikstyringspersonalet, og det kan man ikke.

Banedanmark opdagede fejlen i forbindelse med de afsluttende test, inden strækningen skulle tages i brug. Når Søren Boysen ikke er helt oppe i det røde felt over, at Alstom kan levere et signalsystem uden konstant kontrol med signalerne på alle strækninger, så skyldes det, at nogle af testscenarierne »har meget lav sandsynlighed«, som han udtrykker det.

Se hele Ingeniørens fokus om nye signaler til jernbanen

Derimod er han mere klar i spyttet, med hensyn til, at fejlen ikke er rettet. Det havde Alstom ifølge Banedanmark-direktøren nemlig lovet, allerede da den første gang blev identificeret i efteråret 2018.

»Det er ikke tilfredsstillende,« siger Søren Boysen.

Hvad siger du så til, at Banedanmark selv måtte opdage, at fejlen stadig var der i forbindelse med jeres egne test?

»Det er heller ikke tilfredsstillende.«

Læs også: Danmark ignorerede alle røde lamper for at være først med ERTMS

Nu er bufferen væk

På spørgsmålet om, hvilke økonomiske sanktioner Banedanmark vil iværksætte over for Alstom, nøjes Søren Boysen med at konstatere, at der bliver »et kontraktligt mellemværende«.


I første omgang er det også mere presserende for Banedanmark overhovedet at få planen for at udbedre fejlen på plads.

»Vi har endnu ikke lagt den endelige plan sammen med Alstom for, hvordan vi løser det her og kommer i gang med udrulningen,« siger Søren Boysen.

Læs også: DSB-tog kørte forbi stoplys efter ombygning til nye signaler

I stedet har Banedanmark altså selv estimeret, at løsningen kan være på plads inden udgangen af året. Det er også nødvendigt, hvis det ikke skal påvirke den langt vigtigere, resterende del af Lille Syd-banen mellem Køge og Næstved. Den har Banedanmark nemlig brugt ca. en milliard kr. på at elektrificere og hastighedsopgradere til 160 km/t, og den skal efter planen åbne i 2021.

Den plan indeholder imidlertid kun et halvt års buffer, som forsinkelsen, selv hvis Banedanmarks forudsigelse holder, æder op. Bliver forsinkelsen større, vil det også gå ud over åbningen af banen mellem Køge og Næstved.

Læs også: Banedanmark opgiver erstatning for den mest forsinkede del af nye togsignaler

Med tiden skal den bane også have direkte forbindelse til København via den nye Ringstedbane og Køge Nord Station, men det projekt er også forsinket af signalsystemet. Det venter nemlig på, at der bliver udbygget et analogt signalsystem på Ringstedbanen. Det er nødvendigt, fordi ombygningen af DSB's tog til de nye signaler, som Alstom også står for, er voldsomt forsinket i forhold til de oprindelige planer.

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

så skyldes det, at nogle af testscenarierne »har meget lav sandsynlighed«, som han udtrykker det.

Lyder det ikke, som at man satser på, at det ikke opdages i test??

Det er ikke en god begrundelse for, at det ikke fungerer.

Som jeg ser det, så bør systemet naturligvis tjekke at lamperne lyser, og at pærene ikke er sprunget. Man skal altid have feedback på alt. Så enkelt er det. Ingen output, uden input der tjekker at output er korrekt. Uanset, om der er elektronik, relæer eller mekanik involveret, eller bare en lampe, så skal der altid være et eller flere inputs, der tjekker at output er korrekt. Test sandsynligheden er ligegyldig.

Hvor stor er sandsynligheden for at en transistor fejler? At et relæ fejler? At en lampe er sprunget? At der er ledninger som er skåret/gravet over? Jo, sandsynligheden er meget lav.... Så vi accepterer, at leverandøren ikke har lavet det de har lovet. Test sandsynligheden er lav...

Måske burde det med i test planen at skrue pærerne ud? Hvis ikke spændingen og strømmen er korrekt, bør det detekteres.

Selvom det bare er en LED på et printkort, så tjekker jeg altid, at spændingen over den er rimelig. For det sker at de monteres forkert, eller at der ikke er forbindelse, eller at de får isat en LED med forkert farve.

  • 11
  • 0

Der er standarder for sikkerhedsrelevante systemer. Det er baseret på at minimere fejl i systemer selv om man ikke kan beregne alle sandsynlighederne. (Løst formuleret baseret på topologien).
Hvis man kan beregne sandsynlighederne skal man naturligvis gøre det.
Der er ingen friheder til at gøre hvad man synes.
Og ja tak meget af det ovennævnte.
Men det ville åbenbart være et mirakkel hvis man gjorde det korrekt.

  • 3
  • 0

Lyder det ikke, som at man satser på, at det ikke opdages i test??

Det er ikke en god begrundelse for, at det ikke fungerer.

Som jeg ser det, så bør systemet naturligvis tjekke at lamperne lyser, og at pærene ikke er sprunget.

Din pointe er fuldstaendig korrekt! Ligemeget hvor usandsynligt det maatte vaere skal systemet vaere i stand til at haandtere det.

Vil dog lige pointere at der med det nye signalsystem ikke er fysiske signaler og derfor ikke nogen transistorer, relaeer eller andet. Det er blot en computer i foorerrummet og en forbandet masse kode.

  • 3
  • 0

Der er ingen signallamper i det nye signalsystem. Så der er ingen pærer at tjekke.

Jamen, så overlader man jo styringen helt til computeren? - og hvis den står af, kan togføreren vel ikke køre nogen steder uden visuelle signaler?

Det er da et helt grundlæggende problem med det system:
Ved fejl, vent 4-5 timer mens det fejlramte tog bliver repareret eller bugseret på værksted. Hurra for digitalisering.

  • 1
  • 2

Ved fejl, vent 4-5 timer mens det fejlramte tog bliver repareret eller bugseret på værksted. Hurra for digitalisering.

Vi har jo desvaerre samme problem i dag naar de nuvaerende signaler fejler. Om det nye system bliver mere eller mindre ustabilt maa tiden vise.

  • 4
  • 0

Vi har jo desvaerre samme problem i dag naar de nuvaerende signaler fejler. Om det nye system bliver mere eller mindre ustabilt maa tiden vise.

Ved det eksisterende system, har hver enkelt station sit eget sikringsanlæg og med mindre enten relæhytten brænder eller andre voldsomt hænder, så er stationernes anlæg stadig fungerende, selv om fjernstyringen dør - hvilket sker af og til.

Hvis problemerne er langvarige, så kan man sende personer ud på de enkelte stationer for at styre toggangen - og stadig med det samme sikkerhedsniveau.

  • 1
  • 0

Når det blot er en computer så ville det høre ind under en standard som omhandler sikkerheds relevat software.
I den standard er både soft og hardware og externe enheder inkluderet og naturligvis systemet som sådant.
Under sådan en standard er skabelses processen veldefineret fx hvilke møder og revision som skal udføres.
Til beroligelse for dem som ikke holder af computere inkluderer softwarens opgaver også en løbende kontrol af computerens hardware.
Det er synes jeg meget usandsynligt at man har fulgt sådan en standard og meget forkasteligt.
En flok lallende amatører, hvis man må sige sin mening

  • 1
  • 1

En af de ting som er skræmmende er at der er flere tilfælde hvor man må konstatere at der tilsyneladende ikke er fulgt en releven procedure for udarbejdelse af sikkerheds relevante systemer.
Er det ubekendt i Danmark eller opdager man at det er en masse arbejde ?
Disse standarder er top down standarder, hvilket faktisk kræver at man har erfaring i sådanne systemer. ( Eller en mulighed er måske at programmere systemet fra bunden op og så når man er færdig smide alt ud og begynde forfra) . Softwaren skal sikre at hardware og externe signaler er i orden ved at udføre relevante tests.
Det er ikke muligt at bevise at et program er fejlfrit men man kan da gøre et forsøg. Bla ved at indbygge tracking variable som alarmerer hvis programmet er på afveje. Modul opdeling og revisioner samt sikring af at programmørerne tager hensyn til foreskrevne procedurer og altid har sikkerheden for øje. Endelig skal man teste.

En af de ting som man må bekymre sig om er programmerings sproget. C++ er ikke velegnet uden restriktioner og selv da alt for gammelt. Et mere moderne sprog som mere agressivt er fejlforebyggende er langt at foretrække. De sprog som synes agressivt voksende i anvendelse er Rust og selvfølgelig Julia , her er Rust nok bedst til system programmering medens Julia mere er til store datamængder, kunstig inteligens og videnskablige formål. Go som er googles er også populært.
Men der er frit slag, men tag og send de der C++ programmører på et kursus.

  • 0
  • 0

En af de ting som man må bekymre sig om er programmerings sproget. C++ er ikke velegnet uden restriktioner og selv da alt for gammelt. Et mere moderne sprog som mere agressivt er fejlforebyggende er langt at foretrække. De sprog som synes agressivt voksende i anvendelse er Rust og selvfølgelig Julia , her er Rust nok bedst til system programmering medens Julia mere er til store datamængder, kunstig inteligens og videnskablige formål. Go som er googles er også populært.
Men der er frit slag, men tag og send de der C++ programmører på et kursus.


Jeg kender desværre ikke sprogene du nævner. For mig er de vigtigste faktorer ved sprog at de er deterministiske, således at enhver fejl er reproducerbar ud fra logs. Sprogene skal også være deterministiske, hvis der anvendes parallelisme herunder interrupts. Og hvis der udskiftes hardware må det ikke påvirke resultater. En hurtigere CPU, eller et andet motherboard, en ny compiler osv. må ikke ændre resultater! Dertil skal være muligt at analysere maksimum lagerforbrug deterministisk for alle kritiske dele. De dele, som der ikke kan garanteres lagerforbrug for, må ikke have betydning for sikkerheden. Det betyder, at hvis f.eks. der anvendes rekursiv stak eller pointere, så skal være muligt at køre et program, der regner det højeste mulige lagerforbrug ud. De sikre dele, skal det også være muligt at kunne analysere svartid for. Det dur ikke, at vi kan bevise, at der kommer et svar - men ikke hvornår. Vi skal kunne komme med en maksimum svartid. Og ikke den, som C++ softwarefolk der er eksperter i realtime hoster op med - vores software, kan garantere svartiden, i 99,99% af alle events. Og det syntes vi selv er meget godt, hvis vi selv skal sige det... Det går ikke, og det skal helst kunne matematisk analyseres. Ofte er en god tid, at ikke kun have garanteret svartid, men også sikre at svartiden er eksakt, dvs. at programmeringssproget skal regne ud, hvornår der svares. Og der svares på dette tidspunkt - altid. Og ellers, så er der håndteringsrutiner der opdager fejlen, logger den, og lukker systemet ned, indtil at fejlen bliver undersøgt og de ansvarlige fundet. Jeg har fået at vide, at man i sådanne tilfælde, altid skal springe hovedsikringen. Og sker det mere end tre gange, skal kræves helt nyt hardware.

Normalt, så må man udelukke kunstig intelligens i kritiske systemer, da det oftest har ikke deterministisk natur, og det er svært at analysere konsekvenserne af. Det kan bruges i mange sammenhænge, så længe det ikke er kritisk software. Kritisk software er altid deterministisk, og logbar, så man kan retsforfølge de håbløse softwareidioter som begår brølere.

  • 0
  • 0

Ja man skal vælge sit sprog med fornuft og der er masser af dem.
Selvkørende biler bruger jo kunstig inteligens til billedgenkendelse og man må måbe når tesla står frem og siger at deres selvkørende bil snart er på markedet.
Selv ens egne øjne kan blive snydt og vi har foruden billedgenkendelse er realitets sans.

  • 0
  • 0

"Det lagde nemlig, i de særlige situationer, ansvaret for at overvåge signalerne over på trafikstyringspersonalet, og det kan man ikke."

Hvis systemet er i tvivl om der er fri bane eller ej, skal toget standses. Det er vist første regel i reglerne om failsafe. Ved tvivl = STOP!

  • 1
  • 0

"Systemet ved ikke, om der er rødt eller grønt"

Så kan man stille spørgsmålet: Kan farveblindhed i jernbanesignalsystemer behandles?

I de tilfælde, hvor farveblindheden skyldes en medfødt defekt i signalsystemet, findes der ingen muligheder for behandling eller korrigering.

Eftersom 99 % af alle tilfælde af farveblindhed er medfødt og en naturlig og fordyrende følge af særdeles dårlig udbudsforretning kan tilstanden derfor sjældent behandles.

Ved erhvervet farveblindhed kan farvesynet i enkelte tilfælde forbedres ved at undersøge, om den underliggende årsag til farveblindheden kan fjernes - men det er kun yderst sjældent set, at det har haft konsekvenser for de reelle syndere.

Hvis du bemærker ændringer i dit systems farvesyn, bør du derfor få en aftale hos en kvalificeret systemprogrammør eller din kontrakt skal gennemlæses - og forståes - af en ansvarlige hurtigst muligt.

Selvom farveblindhed i jernbanesignalsystemer sjældent kan behandles, kan du afhjælpe den ved bl.a. at træne dig selv i at huske placeringen af forskellige elementer. Det kan være med til at øge chancen for, at du kan identificere disse elementer og skelne mellem dem, til trods for du ikke kan skelne farverne.

Det gælder blandt andet trafiklys på banestrækninger, hvor du kan lære dig selv at skelne mellem, om der er rødt eller grønt til trods for, at begge farver forekommer grå for dine øjne.

Et trefoldigt HURRA bør ikke mangle.

  • 1
  • 0

Jens D Madsen. Det nye signalsystem (ERTMS) er jo netop ikke baseret på fysiske signaler. Der er derfor hverken lamper eller pærer i systemet!


Nu var det artiklen der nævnte lamper. Ved input gælder naturligvis det samme - ingen input, uden der er tjek på, at det som modtages er korrekt. Typisk, kræves flere uafhængige sensorer, der f.eks. virker omvendt. Graves f.eks. ledninger over, er vigtigt, at det ikke medfører, at der ikke opdages fejl. Sker en mekanisk fejl, må det heller ikke påvirke sensorerne ens, så fejlen ikke opdages. Eller, hvis det skyldes sne, eller oversvømmelse. Normalt laves "fejlsimuleringer" der har til formål at tjekke, at alle tænkte fejltyper opdages.

  • 1
  • 0

Nu var det artiklen der nævnte lamper. Ved input gælder naturligvis det samme - ingen input, uden der er tjek på, at det som modtages er korrekt. Typisk, kræves flere uafhængige sensorer, der f.eks. virker omvendt.


Signalsystemer er ret simpel omkring detektering af tog. Enten bruger man akseltællere, hvor man tæller hvor meget der kommet ind og ud af de blokke eller sporisolatorer, hvor en strøm i skinner bliver kortsluttet af toget. Banedanmark bruger nu mest sporisolatorer og går over til akseltællere med det nye signalsystem. Det er gennemprøvet teknik, hvor man kender fejlmulighederne.

Men der er mange niveauer i signalsystemer. Sikringsanlæget, som håndtere togveje, som være fejlsikker og TMS, som styre toggangen. Det er muligvis i grænsen imellem dem, hvor problemerne er og ikke det basale i interfacet imellem spor og teknik.

  • 0
  • 0