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

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....

hvis de ikke holder øje med om filsystemer løber fulde, jamen hvad er der så ellers de ikke holder øje med ??

nå ja man kan jo ikke få alt for 20 mia kr ...

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.

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.

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

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!

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.

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...

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?

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.

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.

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

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.

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.

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.

en notits forleden, om en tysk patient, der døde, fordi overflytning til at andet sygehus ikke fungerede

Hun døde i ambulancen på vej til et andet hospital - det hospital, hun skulle have været indlagt på, var ramt af ransomware.

https://www.version2.dk/artikel/ransomware-koster-tysk-patient-livet-doe...

Hvis de ingen gang kan overvåge deres egne servere som skal overvåge deres kerne funktion .. er det godt nok op ad bakke for dem :-o

23 milliarder.......Hvordan er det muligt?....

Hun døde i ambulancen på vej til et andet hospital

Tak.

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

Det er formodentlig fordi det ikke er det mekaniske system, som har solgt programmet, men derimod opsætning af KPI'er, og generering af rapporter med farvelade og fine lagkagediagrammer.

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?

... 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)

I forlængelse af #23. Hvis man er interesseret i den standardiseringsmæssige side af ERTMS' kommunikationsdel, kan man med fordel checke dette link hos ETSI:

https://www.etsi.org/committee/1409-rt

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?

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.

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.

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.

Ja, og det var ikke "kun" et enkelt sygehus, men hele region Midtjylland.

... 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.

Nej. ERTMS har ikke noget bloksystemet at gøre.

Fint input, som kaster mere lys over hvad der sker på S-banen (og som bekræfter at jeg - som sagt - ikke kender til forholdene i CBTC).

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 ;)

.. hvad systemet så koster at drive?

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.

Hvor er det en fornøjelse, når folk, der faktisk har sat sig grundigt ind i tingene, diskutterer fakta og gør os alle klogere. Når det lykkes, er det V2s største styrke. Tak Torben, Steen og Nis.