Løb tør for serverplads: Fejl i milliarddyrt signalsystem stoppede S-togsdriften i timevis

Illustration: Mads Lorenzen
Banedanmark ønsker ikke at stille op til interview men henviser til en serverfejl i det 23 milliarder dyre signalsystem.

»Ja så bliver det Svanemøllen og toget kører ikke videre. Vi har fået besked på at indstille al S-togsdrift nord for København,« lød det i et monotont toneleje ud i et propfyldt S-tog lørdag den 19 september.

Læs også: FE-chef om cybertrussel mod signalsystem: Det er mit indtryk, at man er meget opmærksom på den problemstilling

»Vi vil undersøge muligheden for, at I kan køre videre nordpå med togbusser, men I skal ikke regne med dem den næste times tid. Vi ønsker jer en fortsat god rejse.«

Beskeden betød, at de mange hundrede kunder stimlede sammen på perronen og foran den lille nordkøbenhavnske station under coronaepidemien. Men den betød også, at der -igen- var gået noget galt i signalsystemet.

Lille fejl i et stort system

Derfor rettede Version2, der har oplevet dette ske to gange, henvendelse til Banedanmark, der står for det mere end syv år forsinkede og 23 milliarder dyre signalsystem.

Tolv dage efter tikker en mail ind hos Version2.

»Undskyld det sene svar, men her er forklaringen på, hvorfor vi måtte indstille driften på de strækninger, der kører på det nye signalsystem forrige lørdag,« starter den korte mail fra Banedanmarks presseafdeling:

Pladsproblemer på server

»Lørdag den 19/9 opstod der pladsproblemer på en server. Det betød, at systemet, der er med til at vise, hvor på strækningen togene er, begyndte at køre langsommere.«

»Derfor blev der truffet beslutning om at indstille driften på de strækninger, der kører på det nye signalsystem, indtil vores leverandør, Siemens, skaffede den nødvendige plads på serveren. Trafikken var indstillet i godt to timer.”

Det rejser en lang række nye spørgsmål om, hvad Banedanmark og Siemens gjorde forud for hændelsen for at forhindre at dette skete - eller sker igen. Samt om, hvordan manglede serverplads kan have så markant en indvirkning på noget, Center for Cybersikkerhed har defineret som kritisk, dansk it-infrastruktur.
Men Banedanmark ønsker ikke at stille op til interview.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Søren Koch

Det er jo ikke ligefrem fordi der ikke findes systemer til at overvåge servere mm for diskplads og sige til i god tid???

(en simpel df | mail -s 'diskplads på server' admin@host.navn kørt af crontab ville jo gøre det under linux) OK det kræver så at der rent faktisk er nogen der læser den mail hver dag og tager akrion hvis det begynder at se forkert ud....

  • 41
  • 0
#3 Mogens Lysemose

Det fremgår ikke helt om det er disk eller RAM serveren løb tør for. Når den kører langsomt i stedet for at blokere, kunne det godt være RAM, hvor systemet så swapper til og fra page file hele tiden.

Det kan være sværere at forudse end diskpladsforbrug, men hvis det er et langsomt voksende memory leak har man selvfølgelig tid. Hvis man altså kigger/monitorer serveren.

  • 18
  • 1
#4 Claus Wøbbe

Please, kære journalist!

Du skriver "Men Banedanmark ønsker ikke at stille op til interview." Denne formulering er politiker-spin og kopieret fra politikeres udtalelser.

Kunne du ikke i stedet bruge den meget mere præcise formulering "Men Banedanmark afviser at stille op til interview.".

Vi (I journalister) skal ikke pænt spørge hverken politikere eller politisk inficerede virksomheder, om de "ønsker" at udtale sig! I skal forlange, at de står på mål for deres håndtering af skattekroner.

  • 54
  • 5
#5 Maciej Szeliga

Hvad er det der æder plads i et system der reelt set kan være rent mekanisk?

Hvis nogen undrer så er bloksystemer ret simple "if-this-then-that" løsninger (hvis blok optaget så vis rød på indgangssignal og kør langsom på foregående indgangssignal), som naturligvis bliver mere komplekse når der er sporskifter men dog fortsat "statiske" som i at størrelsen afhænger af mængden af signaler og sporskifter i anlægget. Moderne anlæg med korte blokke fylder naturligvis mere da de holder styr på togenes hastighed men det er fortsat statisk da toget kun "eksisterer" i systemet indtil det når endestationen, derefter kan det arkiveres.

Dermed er der kun to ting som kan fylde: * statistik, som burde ligge eksternt i forhold til det egentlige system og ikke stoppe driften af signalsystemet * OS opdateringer, hvis størrelse afh. af valgt OS og vi vil alle der at kun er et OS hvor opdateringer over tid fylder mere end systemet

  • 19
  • 0
#6 Carsten Kanstrup

Der kommer ikke pludselig nye strækninger eller nye S-tog til, så systemet burde aldrig løbe tør for hukommelse, og det ville ialtfald ikke ske med de industriautomationssystemer, som jeg har været involveret i. Der kan f.eks. næppe være den helt store forskel på at styre S-tog og håndtere mange blandinger samtidig i de samme produktionslinjer på en foderstoffabrik, og en sådan kan sagtens have transportveje flettet ind mellem hinanden som sporene på en større banegård.

Noget kunne tyde på, at man har hentet teknologi fra PC/Linux verdenen med dynamisk hukommelsesallokering og mulighed for hukommelsesfragmentering i stedet for at benytte et realtids sikkerhedsoperativsystem, og jeg forstår slet ikke, at det i det hele taget er blevet sikkerhedsgodkendt. Så vidt jeg husker, er netop dynamisk hukommelse bandlyst og så er der ingen server, der kan løbe fuld.

Amatørprogrammering og elendig softwarearkitektur til en formue!

  • 14
  • 7
#8 Robert Winther

Mon ikke systemer, ud over at holde styr på hvor togene er lige NU, også gemmer historikken for, hvor togene var for 1 minut siden. Og en time siden. Og for en dag siden, hvis der nu opstår et behov for at vide dette, eksempelvis i forbindelse med undersøgelse af en ulykke eller andet.

Ikke at det undskylder den manglende overvågning af, om serveren var ved at løbe tør for plads.

Utroligt at Banedanmark ikke vil forklare hvorfor der ikke var overvågning på plads og om den manglende plads skyldes noget så banalt som at ingen havde tænkt på oprydningsrutiner.

Men det kommer jo heller ikke os ved, det er jo ikke vores penge.

Hov, vent...

  • 23
  • 0
#9 Carsten Kanstrup

Historik Mon ikke systemer, ud over at holde styr på hvor togene er lige NU, også gemmer historikken for, hvor togene var for 1 minut siden. Og en time siden. Og for en dag siden, hvis der nu opstår et behov for at vide dette, eksempelvis i forbindelse med undersøgelse af en ulykke eller andet.

Hvad har det med driften at gøre? Selvfølgelig skal der logges en masse; men det er da tåbeligt at stoppe driften, bare fordi et log system løber fuld og/eller ikke længere kan modtage data hurtigt nok.

Der virker som om, at alle S-tog skal vente på, at data logges i et sekundært system, og hvis det ikke kører, blokkerer man også det primære, hvilket er en tåbelig strategi. Hvis der ikke er plads til nye data, så overskriv de seneste og/eller aktiver en alarm, men lad det primære system køre videre. Hvor svært kan det være?

  • 6
  • 3
#10 Martin Kiefer

Den idé PHK kom med på et tidspunkt omkring oprettelsen af en haverikommision for IT systemer lyder mere og mere nødvendig.

Vi havde et nedbrud på et sygehus for nogle dage siden hvor man måtte aflyse operationer og nu et nedbrud ved Banedanmark hvor togene ikke kunne køre.

Og begge steder slipper man afsted med ikke at ville ud med hvad der går galt.

  • 36
  • 0
#11 Maciej Szeliga

Det kunne jo tænkes at trafikken (S-tog) logges således at man i tilfælde af uheld kan kigge tilbage i tiden. Ud over det er der sikkert audit trail så bruger indgreb logges. Alt sammen noget der optager plads.

Ja, det er klart det skal, men det skal ikke ligge og fylde på systemet. Logning (både det første og det andet) bør foregå på logs som kun holder få timers drift og løbende sendes til separat system for arkivering.

Begge systemer, styring og arkivering, skal sende alarmer hvis logs ikke kan arkiveres og i yderste konsekvens kan sikkerhedsafstanden mellem tog øges og hastigheden sættes ned (helt automatisk) så risikoen for ulykker mindskes - alt det kan fortsætte driften sikkert og sende en vink med en vognstang til alle om at noget er galt.

  • 8
  • 0
#12 Carsten R

For den uindviede er alt jo nemt... Du laver en antagelse og bedømmer derfra systemet til at være noget skidt. Hvis systemet var bygget på dine enkle antagelser var driften helt sikkert god, måske med lidt ironi

  • 6
  • 6
#13 Michael Cederberg

Ja, det er klart det skal, men det skal ikke ligge og fylde på systemet. Logning (både det første og det andet) bør foregå på logs som kun holder få timers drift og løbende sendes til separat system for arkivering.

Jeg er ganske enig i at et system bør holde de sekundære funktioner (så som logning) adskilt fra de primære funktioner (så som at sikre at togene kan køre). Man kan være bekymret for om Banedanmark har haft den fornødne forståelse for hvad de købte når det her kan ske. Men måske har vi ikke fået hele historien. Jeg har svært ved at forestille mig at både Siemens og Banedanmark kan være så talentløse. Måske overreagerede Banedanmark fordi de ikke forstod systemet.

Noget kunne tyde på, at man har hentet teknologi fra PC/Linux verdenen med dynamisk hukommelsesallokering og mulighed for hukommelsesfragmentering i stedet for at benytte et realtids sikkerhedsoperativsystem, og jeg forstår slet ikke, at det i det hele taget er blevet sikkerhedsgodkendt. Så vidt jeg husker, er netop dynamisk hukommelse bandlyst og så er der ingen server, der kan løbe fuld.

Systemets opgave var iflg. udtalelsen at vise hvor tognene var. Det er ikke det sammen som at systemet havde til opgave at sikre at to tog ikke kunne ende i samme sektor (dertil findes nok andre systemer der både er simple og deterministiske). Man kan i praksis fint bruge dynamisk memory allokering hvis man sikrer sig at memory ikke bliver ved med at fragmentere. På samme måde som at man godt kan få ethernet til at opføre sig deterministisk i praksis. Der kræves bare at man forstår hvad man laver.

  • 4
  • 1
#14 Klavs Klavsen

For den uindviede er alt jo nemt... Du laver en antagelse og bedømmer derfra systemet til at være noget skidt.

Øhh - den du svarer på - skriver ikke nogen antagelser om systems konstruktion (udover antagelsen at data gemmes og dermed øget diskplads forbrug) og siger intet om systemet er skidt eller ej.

Hvis systemet var bygget på dine enkle antagelser var driften helt sikkert god,

Et systems arkitektur har intet med driften af det at gøre (udover at det kan besværliggøre stabil drift) ?

Driften af et system vil netop indebære at man sikrer sig at alt nødvendigt ER overvåget og at der er opsat procedurer for håndtering af hændelser der vil ramme SLO'en for systemet (helst inden de for alvor mærkes af kunderne) - og HELST at man tager driftsproblemer tilbage til systemets arkitektur og revurderer/forfiner over tid, så man får permanente løsninger på problemer, istedet for konstante alarmer der skal håndteres.

At man kan fejle på disk overvågning er det mest simple - og der man så absolut IKKE må fejle - og systemet BURDE også have været designet bedre, så det havde kunnet håndtere "en sådan forventelig situation" - på en måde så kunderne ikke mærkede konsekvenser heraf.

  • 13
  • 0
#15 Ditlev Petersen

Vi havde et nedbrud på et sygehus for nogle dage siden hvor man måtte aflyse operationer og nu et nedbrud ved Banedanmark hvor togene ikke kunne køre.

Jeg mener, jeg læste en notits forleden, om en tysk patient, der døde, fordi overflytning til at andet sygehus ikke fungerede. Selv om det (nok) er sjældent, at folk ligefrem dør af systemfejl og sammenbrud, så er der problemer, som bør behandles lige så seriøst som et havari med/på et fly. Altså ikke kun en hemmelig intern undersøgelse. Andre skal lære af fejlene.

Så helt enig. Vi savner en havarikommission (som også kan tage fejlslagne it-projekter).

Nu er jeg lidt tilbøjelig til at tælle de mørke timer, men har der ikke været ret mange nedbrud, kapringer og andet "sjovt" de sidste to måneder? Der var en (eller var det to) lande, der fik lammet børserne. Netværket i en dansk region stod af. S-togene stod stille. Svar på coronatest samlede støv. Var der ikke et firma, der lå brak i en uge? At Nem-Id havde lidt problemer, var nok ikke så usædvanligt. Det var heller ikke flere dage.

  • 4
  • 2
#21 Mogens Lysemose

Jeg håber v2 vil sende opklarende spørgsmål til Banedanmark. F.eks.: * Var det RAM eller DISK der løb fuld? * Var det på en central server eller et lokalt system ude på lokaliteten? * var problemet afgrænset eller for hele S-togsområdet? * Er samme problem sket før, og hvor ofte? * Er der noget der forhindre at samme eller lign. Problem sker igen?

  • 19
  • 0
#23 Torben Rune

... men jeg antager at man alligevel benytter de samme principper, og er det tilfældet kommer her lidt teknisk facts (fra ERTMS):

Alle strækninger er delt op i afsnit, og hver afsnit styres som selvstændige systemer med hvert sit automatiske system (computer).

Disse computere sørger i fællesskab for at der dannes køretilladelser til toget. En køretilladelse indeholder bl.a. information om hvor hurtigt og hvor langt toget må køre. Der sendes en køretilladelse 10 gange i sekundet.

Udebliver køretilladelser, skal toget bringes til 0 km/t inden for den afstand den sidst modtagne køretilladels angiver.

Uden for selve sikkerhedssystemet ligger køreplanen (ankomsts- og afgangstider fre stationer). De har ikke noget direkte med sikkerheden at gøre, men sørger for, at der kan opnås køretilladelser ved afgang fra stationen, så køreplanen kan overholdes.

Medvirkende til at skabe køretilladelser er også informationer om hvor de forskellige tog befinder sig. Det sker ved kontakter i skinnerne (baliser) samt informationer om andre forhold, f.eks. om bomme ved en overskæring går ned (og op igen), målere som giver temperaturen på togets bremser, akseltællere osv.

Ud fra dette (som også logges) dannes tilladelsen. Dannelsen rummer dermed et øjebliksbillede af den samlede situation på det afsnit af banen som den enkelte compuer styrer. Normalt logges denne information, så man kan se at tilladelsen er genereret korrekt. Desuden sendes situationsbilledet til nabo-afsnittene så toget kan afleveres uden afbrydelse af køretilladelser, når det passerer fra et afsnit til det næste.

En vigtig del af tilladelses dannelsen er at sikre, at der hele tiden kan nedbremese før en forhindring. Derfor indgår det enkelte togs bremseprofil i beregningen. "Forhindringer" kan være togstationer (som selvfølgelig forekommer forudset), andre tog (som også kan forudses via informationer om deres køretilladelser), og uforudsete som hvis togstammens integritet brydes (hvilket akseltællerne holder styr på), eller togets bremser løber varme.

I ERTMS er kardancen 100 mS, så selv et beskedent antal tog på et beskedent antal afsnit genererer en anseelig mængde data. Det kan selvfølgelig forudses, og bør ikke føre til at man pludselig står med et kapacitetsproblem på hverken diske eller netværk. Omvendt skal der ikke så mange forkerte settings til, for at en "uskyldig logfil" pludselig kan eksplodere.

Jeg hæfter mig ved, at pressemeddelelsen siger, at »Lørdag den 19/9 opstod der pladsproblemer på en server. Det betød, at systemet, der er med til at vise, hvor på strækningen togene er, begyndte at køre langsommere.«

Mit gæt: ERTMS kører videre men køretilladelserne kan ikke holde kardencen. Når det sker vil alle tog (afhængig af køretilladelser) begynde indbremsning inden for den køreafstand tilladelsen har givet. For visse strækniner betyder det at indbremsning påbegyndes inden for få sekunder, for så at ophæves igen når næste tilladelse når frem. Det giver en ubehagelig drift, og derfor vælger man at stoppe.

En fyldt disk kan naturligvis godt forårsage denne type reaktion, men der må være mere til historien, fordi man i sådanne systemer selvfølgelig tager højde for fyldte diske.

Mere om ERTMS: https://en.wikipedia.org/wiki/European_Rail_Traffic_Management_System

(denne wiki indeholder mange gode links til anden relevant information)

  • 16
  • 0
#25 René Madsen

fordi man i sådanne systemer selvfølgelig tager højde for fyldte diske.

Det er jo en antagelse, men har man nu også taget højde for det?

Har man den fornødne overvågning der advarer i trin, så man allerede får at vide når disk/ram forbruget pludselig vokser uden for de forventede rammer?

I sådan et setup med de prissedler, så bør der være en overflod af målepunkter på, hvordan serverne der drifter det her har det. Har man sikret det samme på CPU belastningen og køre løsningen i et virtuelt miljø, så det er hurtigt at skallere op ved blot at kyle mere hardware ind i sit rack?

  • 4
  • 0
#26 Albert Nielsen

Men den betød også, at der -igen- -igen- -igen- -igen- -igen- ... var gået noget galt i signalsystemet.

Ganske vist er togdriften næsten lige så vanskelig at styre som seksualdriften, men det er imponerende, med hvilken dillettantisme den kan u-styres.

  • 5
  • 0
#27 Steen Christensen

Er der ingen der undrer sig over at de taler on een server? Jeg vil da håbe at disse systemer er designet til at køre i fuld redundans i active/active mode fordelt over minimum 2 datacentre (Helst 3, så der kan besluttes et quorum hvis der er et system der begynder at opføre sig mærkeligt.).

Det her må bare ikke kunne ske.

  • 7
  • 0
#29 Steen Thomassen

... men jeg antager at man alligevel benytter de samme principper, og er det tilfældet kommer her lidt teknisk facts (fra ERTMS):

Alle strækninger er delt op i afsnit, og hver afsnit styres som selvstændige systemer med hvert sit automatiske system (computer).

Nej. ERTMS har ikke noget bloksystemet at gøre. Der er mange lag i systemet. ERTMS er et lag, som kun tager sig af køretilladelser ud fra sikringsanlæget status. Blokke styres i sikringsanlæget og der er i Danmark et akseltællesystem, som holder styr på om et afsnit er besat eller ej. Og det kan godt dække et stort område. Men S-tog bruger med CBTC ikke blokke. CBTC holder styr på hvor alle tog er, så giver det tilladlese efter det sammen status på sporskiftere og andet udstyr.

Disse computere sørger i fællesskab for at der dannes køretilladelser til toget. En køretilladelse indeholder bl.a. information om hvor hurtigt og hvor langt toget må køre. Der sendes en køretilladelse 10 gange i sekundet.

Hyppigheden er variabel i ERTMS/ETCS. Og det er ikke flere gange i sekundet. Det kan gives tilladelser, som er så lange, at man kan kommer igennem et radiodødt område. Og hvis det er niveau 1, gives nye køretilladelser kun ved passage af baliserne.

Udover sikringsantal og CBTC (og ERTMS/ETCS) er der servere, som håndtere fx afvikling af køreplanen og andre støttefunktioner, som ikke er sikringskritiske, som kører på alm. server med OS som Unix og Windows. De burde have være dubleret.

  • 8
  • 0
#31 Nis Schmidt

Er fortrinsvis at ERTMS kører med noget der ligner faste blokke og CBTC benytter rullende blokke. OG det er de to signalsystemer tilsammen, det koster 23 mia!

Det sidste burde vel være sendt til journalisten, men så slipper han for at svare den mail - og så tilbage til emnet :)

Nytten af en "IT-haverikommission" er mest, at når en fejl (ulykke) er sket ,kan eksperterne, der selv er blevet klogere af skade, kloge sig på hvordan man kan undgå, at fejlen gentages. Det er SVjV sådan man gør på baner - og så vidt jeg kan se er det også sådan vi gør her ;)

  • 3
  • 0
#33 Steen Thomassen

Nytten af en "IT-haverikommission" er mest, at når en fejl (ulykke) er sket ,kan eksperterne, der selv er blevet klogere af skade, kloge sig på hvordan man kan undgå, at fejlen gentages. Det er SVjV sådan man gør på baner - og så vidt jeg kan se er det også sådan vi gør her ;)

Havarikommissionen for jernbane og luftfart går kun i alvorlige sager. Dette er en simpel hængelse, som påvirkede drift voldsomt og som svækker tilliden til driftstabliteten, men ikke påvirker sikkerheden. Og det kan ret hurtig kan håndteres lokalt.

Det er mere behov for en evaluering, når et projekt er løbet af sporet. Statens It-projektråd, som håndtere overvågning af store projekter, hjælper til at undgå at det sker.

  • 1
  • 0
Log ind eller Opret konto for at kommentere