Treinstoring NL kwam door kapotte back-up telefonieservers

ProRail heeft meer details gedeeld over de telefoniestoring die er donderdagavond voor zorgde dat het treinverkeer ontregeld werd. Het probleem lag niet bij GSM-R dat in mei voor een storing zorgde, maar bij een losstaand telefoniesysteem voor contact met machinisten.

Op basis van voorlopig onderzoek zegt ProRail dat het probleem lag bij een telefoniesysteem waarvan servers staan in Amsterdam en Rotterdam. Het probleem lijkt te zijn ontstaan bij de Rotterdamse telefonieservers. Hierbij wilde ProRail overschakelen naar de back-upserver in Rotterdam, maar ook deze server werkte niet.

De tweede back-upserver in Amsterdam werkte wel, maar tijdens het terugvallen naar deze back-up 'zat een periode waarin het telefoniesysteem nog niet stabiel werkte', schrijft ProRail. Daarom werd besloten om al het treinverkeer te staken.

Dit telefoniesysteem is een ander systeem dan het GSM-R-systeem dat in mei voor een treinstoring zorgde. Het telefoniesysteem, dat ProRail een INTtel-systeem noemt, zorgt voor communicatie tussen treinleiding en machinisten. Onder meer seinen werkten wel, alleen hadden machinisten in het geval van een incident geen contact kunnen opnemen met de treinleiding. Daarom werd uit voorzorg het treinverkeer gestaakt.

Het INTtel-systeem en GSM-R worden beide beheerd door Mobirail, een samenwerkingsverband van KPN, Nokia en Siemens. ProRail blijft onderzoek doen naar de storing en zegt de definitieve resultaten te willen delen. De telefoniestoring duurde van 17.30 tot 19.00 uur. Ook na 19.00 uur bleven treinen echter maar mondjesmaat rijden. Sinds vrijdag rijden de treinen weer volgens de dienstregeling.

Reacties (108)

[Upsilon]

Zo zie je maar hoe nuttig het is om op reguliere basis dergelijke uitwijkscenario's te testen

[DaMightyWackO]

Klopt uitwijk testen zijn heel nuttig, maar ook lastig voor grote (oude) bedrijven. Ik heb ervaring met uitwijk testen bij de NS. Oh boy wat een circus om op te tuigen. 50+ (externe) partijen en afdelingen/teams om aan te haken. Dienstverleners, intere afdelingen, leveranciers, afnemers, partners (denk aan de Duitse en Belgische spoorbedrijven die afhankelijk zijn van NL informatie). Dit was bijna een fulltime job om te organiseren 2x per jaar. En het levert in zo een landschap altijd onderbrekingen op (er zullen betweters zijn die zeggen dat het dan niet goed ontworpen is etc, maar dit is de praktijk) en daarom zit niemand er op te wachten en mocht dit 2x per bij hoge uitzondering op zaterdagnacht 0300h. En dat kost veel geld in voorbereiding, uitvoering (allemaal partijen die nacht/weekend tarief vragen. En nee uitwijken zijn in de praktijk weinig contractueel geborgd) en je had er ook nasleep van. Er was altijd wel een applicatie die niet meer direct in de lucht kwam. Ik zou er een boek over kunnen schrijven, denk er niet te simpel over. Het is echter geen reden om het dan maar niet te organiseren; want de les voor mij is wel: hoe vaker je dit doet, hoe beter je er in wordt en hoe minder de impact.

[jongetje]

Dan is de vraag of een uitwijk wel zin heeft als het zo enorm veel geld en tijd kost. Dan is dit alleen maar nuttig voor als er een brand uitbreekt in een datacenter.

Qua telefonie zou je verwachten dat je eenvoudig kunt overschakelen (en dit zelfs om de week kunt doen). Al vind ik anderhalf uur nu niet zo heel enorm lang om 2 keer over te schakelen in dit geval. Vooral het tijdstip (in de spits) maakt het extra vervelend.

[casberrypi]

Liever nog decentrale systemen waarbij het uitvallen van een deel niet tot het onbeschikbaar zijn van het geheel leidt.

En dan iets als https://netflix.github.io/chaosmonkey/ erin om te zorgen dat je gegarandeerd regelmatig deelsystemen mist zodat je niet per ongeluk wel ergens een SPOF introduceert.

[tweazer]

Is een duo-sim oplossing in telefoons niet een simpele oplossing ? Elk gelieerd aan een eigen operator/sip centrale natuurlijk ...
Voor testen hoeft het primaire systeem niet onderuit, enkel het secundaire systeem dient geraadpleegd te worden ...
Ik meen dat je ook een nummer bij 2 endpoints uit kunt laten komen, mits dat redundant is, is het plaatje compleet ?

[Reactie gewijzigd door tweazer op 28 juli 2024 10:31]

[tss68nl]

er zullen betweters zijn die zeggen dat het dan niet goed ontworpen is etc, maar dit is de praktijk

Die twee dingen hebben niets met elkaar te maken. Iets wat in de praktijk fout gaat kan prima slecht ontworpen zijn. Sterker nog, het kan zelfs de directe aanleiding zijn.

Als er 50+ partijen nodig zijn om een uitwijk te testen, dan wil dat zeggen dat je dus ook die 50+ partijen nodig hebt als er écht iets om valt? Er zal maar net even één partij niet bereikbaar zijn.

Dat is simpelweg het probleem met uitwijk scenarios. Ze zijn zó slecht ontworpen of half uitgevoerd dat het in de praktijk niet levensvatbaar is. En de enige oplossing is: jawel...beter ontwerpen en ook daadwerkelijk het ontwerp volledig realiseren. Dat vergt een sterk ontwerp, en vervolgens aansturen van de andere partijen om hun systemen dusdanig aan te passen dat de partij niet meer nodig is voor een uitwijk.Veel werk, maar het scheelt ook veel werk uiteindelijk.

[Hangtime]

Leuke theorie, probleem is dat Den Haag ook nog invloed heeft.
Je kan daar wel inhoudelijke verhalen gaan vertellen, maar daar hebben ze politieke schijt aan ;-)

[tweazer]

In de jaren 90 was IBM DE leverancier van uitwijk en redundantieoplossingen. Spare datacenters, ge-syncte data, engineers paraat. Meestal ging een test of een echte uitwijk goed (je zag dan ineens ibm bussen in amsterdamse datacenters pareren). Soms ging het goed fout, dan was de failover niet beschikbaar of werkte gewoonweg niet. Het valt en staat met budget, belangen, oefenen en last but not least mensenwerk. Vaak gehoord in die tijd waren versleten backup tapes omdat men keer op keer op dezelfde media backups schreef, niet teste en vooral niet verving na tig keer dezelfde tape te gebruiken. Dure/complexe dingen neigt men meer aandacht te geven dat laag bij de grondse dingen zoals media, kabels en wie (paard en wagen) doet wat waar wanneer ...

[MatthiasL]

Met nadruk op was. Momenteel gebeurt het ongeveer 1x per maand en is het best een goed lopend proces.

[aaten]

Ik werk ook bij een groot en oud bedrijf maar we switchen om de haverklap. Daar was eerst wat moeite voor nodig om het voor elkaar te krijgen maar maakt je leven uiteindelijk zoveel makkelijker en veiliger. Een heftige switch duurt nu nog 30 seconden (onverwacht en automatisch), dan is alles weer in bedrijf. Gepland switchen merkt niemand.
Klinkt meer alsof de NS/ProRail hier nog nooit het belang van in te zien en dat is toch wel kwalijk te noemen.

[vandijk]

Als de failover naar de backup al lastig is, zo is de weg terug soms nog veel lastiger. Tijdens dit soort acties kom je ongepatchte machines tegen, documentatie die niet uptodate is, falende hardware etc.

Grootste denkfout die gemaakt wordt, is het (proberen) ontwerpen van systemen die niet kunnen falen. Dat gaat altijd wel een keer gebeuren. Soms door de stomste oorzaken. Schoonmaker die een emmer sop in je server gooit bijvoorbeeld.

Ga er voor het gemak maar vanuit, dat er iets kan falen, en zorg dat de individuele componten hier tegen kunnen. Ook niet simpel, maar dan hoeft niet de hele keten in 1x over.

Ook een mooie kosten besparing: gebruik de acceptatie omgeving als failover voor productie. Lullig dat afnemers van jouw dienst niet verder kunnen met een change die je zelf opgelegd hebt.

[tweazer]

Soms door de stomste oorzaken. Schoonmaker die een emmer sop in je server gooit bijvoorbeeld.

Ervarvingen:
koeling op maximaal vermogen zetten na een airco outage -> ineens laag water op zaal
datacenter in de kelder want die is vrij -> overstroming bij een regenbui
koeling geen onderhoud geven "want datacenter wordt niet meer gebruikt" -> kritieke apparatuur in storing
stroomverbruik erg hoog ondanks virtualisatie -> wietplantage
's-nachts voetballen op datacenterzaal -> noodknop wordt geraakt
tegen kast aanleunen -> aardbevingsdetector wordt geactiveerd, dataset gewiped om inbraak te voorkomen
tegen kast aanleuen -> powerstrip kontakten waren niet vastgeprikt, enkel ingeduwd. dat verklaarde eerdere issues
kabels onder de vloer opruimen -> wel in gebruikte kabels worden weggeknipt door ijzer(koper)handelaar
en zo heb ik er nog veel meer ...

IT/ICT blijft mensenwerk, zolang het goed gaat schuift die perceptie naar de achtergrond qua waardering, budget en gedrag

[jbhc]

Je laat toch niet een oud ijzer boer kabels wegknippen in een datacenter? Dan wil je gewoon dat het mis gaat.

[mutmong]

...de kwalijke ziekte van 'moeten uitbesteden aan de laagste bieder'. Hebben we in België bij Infrabel ook redelijk last van!

[The Zep Man]

Grootste denkfout die gemaakt wordt, is het (proberen) ontwerpen van systemen die niet kunnen falen. Dat gaat altijd wel een keer gebeuren. Soms door de stomste oorzaken. Schoonmaker die een emmer sop in je server gooit bijvoorbeeld

Fysiek serverfalen (of datacentrumfalen, denk aan een langdurige stroomuitval) valt gewoon tegen te ontwerpen. Uiteraard kan elk systeem falen, maar voor veel van dit soort kleine scenario's kan je je met brede maatregelen daartegen beschermen.

Een probleem wat bij de NS meespeelt is legacy en technical debt.

[Reactie gewijzigd door The Zep Man op 28 juli 2024 10:31]

[Transferno]

Uitwijk en DR testen zijn altijd een hel om te doen. Ook al door het risico van de test zelf. Daarom heb ik liever volledig geo redundantie systemen waarbij ook continue verkeer over elke locatie gaat. Dan heb je wel een kostelijke oplossing, maar weet je wel dat alles optimaal werkt.

[Yolo]

Men overschat het testen van de uitwijk als men niet voorziet in het testen van de kleine afhankelijkheden. Ik denk dat je mag aannemen dat een backup systeem als deze prima getest kan worden zonder een hele omgeving uit te wijken, even smoketesten of de basis werkt om goed voorbereid te zijn op een uitwijk(test)

[Frame164]

Het probleem is dat je binnen een 24/7 organisatie zpn fail-over zou moeten testen met alle risico's van dien. En verder is een fail-over onder gecontroleerde omstandigheden altijd anders dan "in het echt". Als je een fail-over test doet, doe je dat 's nachts als er zo min mogelijk verkeer is. Als het tijdens piekuren uitvalt heb je een totaal andere situatie. Netwerk valt uit, je doet een fail-over en honderen of duizenden devices gaan zich tegelijkertijd weer aanmelden. Ongecontroleerd. Dat valt vrijwel niet te testen.

[Ruuddie]

Yes, en dan heb je om 3.00 je failover gedaan maar het ging mis waardoor er om 6.00 nog steeds downtime is. Dan beginnen een hele hoop mensen opeens wel te zweten. Laat dat twee keer in drie jaar gebeuren, en je mag nooit meer hoor van het management. Dan is het de afweging wat een groter risico is: gegarandeerd soms down omdat 1 op de X keren er toch iets fout gaat, of gewoon hopen dat er nooit een storing is.

[Reactie gewijzigd door Ruuddie op 28 juli 2024 10:31]

[Cergorach]

Wil je het wekelijks testen of zo? En dan nog, dan test je het en werkt het niet. Same issue zou ik denken aangezien het issue zat in de failover.

[BiLLY_daKid]

Banken moeten kernsystemen ook periodiek laten uitwijken en bewijs voor DNB. Ik snap niet dat deze kritische infrastructuur niet eenzelfde soort regels kent.

[J_van_Ekris]

Het moet ook maar kunnen. Ik heb ooit een Noodstroom Aggregaten (NSA) getest van kritieke infrastructuur, waar we een start via de No-Break wilden doen. Men teste maandelijks en was overtuigd dat het niets uitmaakte. Na veel aandringen en 5000 handtekeningen later bleek de no-break en accus te zwak voor de startmoter van de NSA.

Maar de klant maakte terecht het punt dat de test niet routinematig kon: kritieke infra periodiek door het donker jagen voor die laatste 1% aan onmerkbaar falen is soms riskanter dan het risico lopen.

Met kerncentrales testen we de tertiare beveilingen na oplevering ook niet meer: als bij de test een issue ontdekt wordt heb je een meltdown te pakken.

Dus zonder kennis van zaken roepen "dat test je toch gewoon periodiek" is echt te makkelijk geroepen.

[jbhc]

Ik vraag mij af waar je het over hebt. NSA's hebben aparte accu's voor de startmotor (een NSA is over het algemeen gewoon een scheepsdiesel)
En de spanning vanaf het NSA wordt pas ingeschakeld zodra het NSA een stabiele bedrijfssituatie heeft bereikt.

Een NSA maakt echt geen gebruik van de No-Break om te starten.

[J_van_Ekris]

Ik vraag mij af waar je het over hebt. NSA's hebben aparte accu's voor de startmotor (een NSA is over het algemeen gewoon een scheepsdiesel)

Klopt, en die accu's hebben (zeker de oudere loodaccu's die toen gebruikt werden) een serieuze component onmerkbaar falen die je pas ontdekte als je het laadcircuit volledig afkoppelt en door het donker heen gaat starten en je accu's op hun piekbelasting gaat testen. Zeker met oudere installaties is het continue garanderen van het benodigde piekvermogen van je accu's een crime.

Een NSA maakt echt geen gebruik van de No-Break om te starten.

Dat ligt aan je ontwerp. In dit geval hadden de ontwerpers hun risico-analyse heel goed gedaan, en geconcludeerd dat zelfs met frequent testen het vermogen van je start-accu's niet gegarandeerd voldoende was om een goede start te maken met de diesels (meervoud) om de vereiste beschikbaarheid te halen. Daarom had men een fallback schakeling bedacht waarbij de no-break een stuk vermogen levert om de diesels alsnog aan de gang te krijgen. Men was zelfs zo verstandig om de no-break goed te dimensioneren dat zelfs bij volledig depleted NSA-accu's dit zou kunnen. Daarmee heb je twee volledig onafhankelijk falende voedingen voor de NSA, en kon men redelijkerwijs uitsluiten dat de NSA zou falen.

Maar twintig jaar later, toen wij gingen testen, was men die redenatie allang vergeten. De NSA werd getest, maar alleen in een regulier start-scenario, dus zonder volledig door het donker te gaan (met het "voordeel" dat je piekvermogen deels via je laadcircuit kunt onttrekken, en dus niet via een chemische reactie van je accu). Men controleerde de toestand van de loodaccu's wel (inspectie en densiteitsmeting), maar kromtrekkende platen zijn erg lastig te zien. Bij een ontkoppelde test zakte het vermogen van de accu's onder de kritische grens, en vielen de diesels dus weer af. Het fall-back scenario van energie betrekken van de no-break stond nog in het draaiboek, alleen daar zag je dat men dat extra vermogen had gebruikt voor uitbreiding van de gebruikers en dus klapte die ook als een kaartenhuis in elkaar.

Het punt is: elk complexer systeem kent wel onmerkbaar falen, zeker als je het over installaties hebt die veel standby staan en niet of moeilijk getest kunnen worden. Dat is wat testen zo belangrijk maakt, maar ook zo lastig.

[Reactie gewijzigd door J_van_Ekris op 28 juli 2024 10:31]

[jbhc]

Ok, zo. Bedankt voor je duidelijke uitleg.

[Cergorach]

Natuurlijk, maar hoe vaak is dat? Elk jaar, zes maanden, drie maanden? De laatste storing is van 3.5 maanden geleden. Als ze het daarna opnieuw een DR test hebben gedaan kan dat minder dan 3 maanden geleden zijn dat dit is gebeurd. Iets werkt totdat het niet meer werkt dat kan vijf jaar gelden zijn, dat kan een week geleden zijn. Het zal niet de eerste keer zijn dat er een DR test wordt uitgevoerd (zonder een constante productie belasting) en bij een daadwerkelijke uitwijk de boel inklapt omdat het niet (meer) de constante belasting aan kan.

Edit: DR tests zijn er om risico te verkleinen, niet om die geheel uit te sluiten, want dat kan gewoon niet. Er wordt hier niets gezegd over hoe vaak dit wordt getest en hoe, dus dit is allemaal puur speculatie.

[Reactie gewijzigd door Cergorach op 28 juli 2024 10:31]

[ToolkiT]

Er zit een groot gat tussen wekelijks en nooit..
Veel systemen word minstens 1x per jaar een DR test gedaan om te kijken of het process werk en alle componenten het doen..

Ja als je een change met een probleem uitrolt in zowel primary als secundary site, maar dat is meer een testing issue dan een HA/DR issue..

[Blokker_1999]

Maar je zou alsnog niet de eerste zijn die vandaag test of alles goed werkt en overmorgen alsnog in een situatie terecht komt waarbij je failover alsnog faalt.

Niet testen is niet goed, maar testen biedt geen garantie dat het goed zal gaan op het moment dat het nodig is.

[InjecTioN]

Precies dat. "De in het verleden behaalde resultaten, zijn geen garantie voor de toekomst."

Er is mij daarnaast altijd geleerd dat je geen aannames moet doen. Aannames zorgen er gewoon voor dat je, keer op keer, van een koude kermis thuis komt.

[Upsilon]

Hoe vaak je het zou moeten testen hangt volledig af van de waarde die je toekent aan de beschikbaarheid van het systeem. Als het resultaat is dat de volledige dienstverlening van je grootste klant plat ligt dan wil je het wellicht vaker dan eenmaal per jaar testen, maar daar hangt natuurlijk wel een prijskaartje aan. De vraag die ProRail zich in dit geval zou moeten stellen is welke kosten ze willen maken om een dergelijk scenario in de toekomst te voor te zijn.

[Qwerty-273]

Buiten de fysieke kant of een server / lijn wel of niet werkt. Is een DR scenario ook ideaal om de processen helder te houden bij het beheerteam. Dat zou minstens jaarlijks uitgevoerd moeten worden.

[Kevinp]

Ik weet niet hoe vaak het getest wordt. Maar het zou met enige regelmaat getest moeten worden. Er is altijd kans dat het toch niet werkt.

Ook kan je met het testen erachter komen dat het niet werkt en als je dan storing hebt heb je ook pech natuurlijk.

[kr4t0s]

En back-up lijnen, servers en andere systemen monitoren. Kom dat regelmatig tegen in de praktijk, storing op hoofdlocatie, blijkt back-up lijn niet te werken. Na onderzoek blijkt die lijn al 1,5 jaar eruit te liggen bijvoorbeeld. Minstens 1x per jaar een uitwijktest en monitoring en probleem is opgelost.

Die grote 112 storing 2-3? jaar geleden had dezelfde oorzaak, bleken twee back-up lijnen gewoon niet te werken. 1 was niet afgemonteerd aka kabel zat er niet in en andere was al +6 maanden down.

[Reactie gewijzigd door kr4t0s op 28 juli 2024 10:31]

[Nox]

Heb je daar meer informatie/bron van? Wat ik begreep was het een softwarefout die op alle drie de systemen voor problemen zorgde.

[vandijk]

"Softwarefout" is een heel ruim begrip.

[Nox]

Een stekker die ergens niet in zit is heel ver weg van een softwarefout

[tweazer]

Meestal als ergens rook uitkomt is het geen softwarefout

[mutmong]

Het is maar hoe je het uitlegt

[gaitjan2]

Over dat laatste hoorde ik een KPNner vertellen: alle systemen werden tegelijkertijd geupdate.

[Transferno]

Geen zin om 3 nachten te werken en het dan maar in dezelfde nacht doen?
Tja, dan had een goed change management dit wel tegengehouden.

[tweazer]

Oei, dat klinkt een beetje als die hackpoging van een universiteit waar men als POC een open source module een update gaf. Die POC bleek erg snel opgepakt te worden door de top 200 in de wereld .... Het venijn zit in de details van een update, zolang het goed gaat geeft men updates steeds minder aandacht...

[raymonvdm]

Je zal niet de eerste zijn waar blijkt dat finance de backup lijn heeft opgezegd i.v.m kosten :-)

[yzaazy]

Ik wilde het net ook zeggen, uitwijkscenario's zijn belangrijk om de continuïteit te bewaken.

[flossed]

of een green blue setup waarbij je elke maand de actieve node switched. Ik heb vaak gezien dat de uitwijkscenarios 1 keer getest worden bij de opelevering. omdat de impact te groot is. Bij KPN hebben ze in het velden succesvol een uitwijk scenario getest met een full restore van een backup, Er waren verschillende backups gemaakt, dagelijks, wekelijks maandelijks, prachtig allemaal. in de tijd werd het op tape gemaakt. alleen vergat men nieuwe tapes in de machines te zetten. Dus toen het moment kwam om daadwerkelijk een backup te restoren, bleek al het magnetische materiaal verdewenen was, de backup schema werd wel regileus gevolgd, want het was goed. ....

[MeNTaL_TO]

Ik neem aan dat na een backup ook een verificatie plaats vind en dus gemerkt wordt dat de media niet meer goed is? Met alle taperobots waar ik mee gewerkt werd, werden tapes soms te snel uit de pool gegooid om vervangen te worden, maar goed liever te vroeg dan te laat.

[flossed]

oud spul waar ik het over had, was in 1997 gebeurt, met mainframes systemen A2200, die stamden op hun beurt weer van een decennia eerder. nee controle zat er niet in. probleempje met het declaratie systeem destijds

[Transferno]

Maar gaat het in dit artikel niet over backups systemen (bv: TAS) i.p.v. backups van de data?

[flossed]

Zout en slakken, maakt niet uit. Volgens mijn gaat het er om dat continuiteit van een bedrijfsysteem niet geregeld was met alle gevolgen van dien. Tevens haalde ik een verhaal aan van een partij die ook met deze utival te maken heeft. Maar goed dat maakt niet uit. Als je 24/7 bedrijfsystemen ondersteund moet je op papier en in mijn opinie ook in praktijk meer doen dan geld innen voor de service, maar ook de service uitvoeren, testen, onderhouden en wat al niet meer. Dat gezegd hebbende, ik heb in vrij veel organisaties gewerkt, en ik ben zelden een deftige oplossing tegen gekomen. Alleen in het rekencentrum van Belgacom destijds, was ik onder de indruk van wat ik zag staan. in mijn opinie is het asllemaal relatief schrijnend. En het is een wonder dat alles blijft werken, maar vaak is het niet dat er een deftige technische systeem de reden is van continuiteit, maar mensen die dag en nacht aan systemen schroeven om ze draaiende te houden. De techniek is er vollop aanwezig om dat niet te hoeven doen, maar het toepassen is een ander verhaal zo stelde ik bij een klant voor om mediwsche gegevens via een eigen VPN tunnel aan te leveren tussen sites. de techische beheerder gaf aan dat de kostprijs om dat voor elkaar te krijgen 70000 euro was per jaar.... Ik zou niet weten hoe iemand aan zo een bedrag komt, tenzij je dedicated 1 FTE naar zo een aparaat laat kijken een heel jaar. want de hardware en sesrvice kosten van VPN apparatuur is maar een fractie van dat bedrag. En op die manier wordt allerlei bedrijfsonveilige zaken geintroduceerd..

[freedzed6]

De werkelijkheid:
Zoals de Terminator 3 film. Arnold en Co komen aan het einde van de film een bunker binnen.
De apparatuur die er staat komt uit de jaren 50-60.

Succes met opstarten

Grootste probleem is gewoon het onderhoud. Ik zie dataracks vol staan met SunServers of PABX met titel: PTT eigendom.
Hoe het werkt, aangesloten is en wie het beheerd? Geen idee maar uitzetten doen ze liever niet.
Men laat het draaien en bouwt er dan iets naast, want Piet en Bert zijn is al 10 jaar geleden met pensioen gegaan.

[tweazer]

PTT is van 1984 ongeveer, zo oud zal dat spul toch niet zijn ? Toen leverde sun nog motorola 680X0 servers als ik mij niet vergis ???

[tweaker2010]

PTT Telecom heeft als aparte identiteit bestaan tot 1998, laatste jaren onder de vlag van KPN maar toch.

[citegrene]

Wel apart dat ze niet vaker testen. Treinen rijden doorgaans 's nachts niet, lijkt mij een groot genoeg window om dit met regelmaat te kunnen testen.

[Z80]

Je kunt testen tot je een ons weegt. Redelijk wat ervaring mee opgedaan bij vorige werkgevers.
Als tijdens een incident tijdens de handover de uitwijkserver om wat voor reden dan ook hikt ben je de klos. Nu blijkt er nog een derde uitwijk server te staan waarnaartoe geschakeld werd. Deze pakte het wel op. Maar de hik in de handover van de eerste uitwijkpoging heeft blijkbaar iets verstoort.
Dit ga je er met testen niet uit halen. Tenzij de verstoring die is opgetreden bij de eerste uitwijk vaker voorkomt.

[J_van_Ekris]

En het punt is wat je dan test. Met complexere systemen zoals deze zie je vaak dat een nachtelijke test bij weinig load je ook weinig leert. Pas als de druk er tijdens een spits op staat en honderden cluents tegelijk authenticatie beginnen bij een bootend systeem, dan weet je echt of je back-up systeem op kan komen als je het nodig hebt.

En vergeet niet: het kan een fundamenteel probleem zijn dat je een systeem niet tijdens piek-belastingen op kan komen omdat tegelijk een proces runnen én honderden authenticaties afhandelen én een queue aan backlogged messages op piekbelasting wegpoetsen gewoon teveel is.

Bij SCADA systemen zie je dat vaak: een SCADA starten in een koude installatie gaat fluitend, en daarna zal alles megasoepel verlopen. Maar een fail-over of reboot tijdens een complexe operatie in een grote installatie kun je vaak vergeten. Het is te veel, te rommelig en de vele retry's en authenticaties die in queue's staan blazen een bootend systeem gewoon omver. Dan kun je beter even het proces tot rust laten komen en dan rustig de boel overpakken.

[wildhagen]

Ook 's nachts is er nog altijd behoorlijk wat treinverkeer hoor. Een aantal nachttreinen, maar vooral goederentreinen rijden in de nacht volop, juist om de drukke rijpaden overdag te vermijden.

Daarnaast vind er in de nacht ook nog rangeerwerk plaats. Denk aan het enorme rangeerterrein bij Kijfhoek, maar ook elders op kleine emplacementen.

[Reactie gewijzigd door wildhagen op 28 juli 2024 10:31]

[SilentDecode]

Je was mij écht voor. Ik was dit ook van plan te zeggen namelijk

[gekeren]

Ik zit met een vraag.
Naar ik begreep konden seinen en wissels gewoon bediend worden.
Daarmee lijkt me de primaire veiligheid gegarandeerd.

Als mijn info klopt dient gsm-r vooral om bij incidenten contact op te kunnen nemen met de verkeersleiding.


Klopt dat allemaal? Iemand die het weet?

Want als dat het geval is, zou ik zeggen, waarom niet een geheim noodnummer voor dit soort situaties?
Gelijk alles plat gooien, dat moet toch anders kunnen?

[J_van_Ekris]

Daarmee lijkt me de primaire veiligheid gegarandeerd.

Als mijn info klopt dient gsm-r vooral om bij incidenten contact op te kunnen nemen met de verkeersleiding.

Ik zou in dit draadje kijken, en dan met name de comments van @EDIT die heel verhelderend werken vanuit het perspectief van een machinist.

De samenvatting: seinen en wissels houden treinen bij elkaar weg, maar bij calamiteiten, waaronder ook zaken als bijvoorbeeld ook spoorlopers, dan moet men heel snel iedereen in de omgeving kunnen waarschuwen om dodelijke ongelukken te voorkomen.

Want als dat het geval is, zou ik zeggen, waarom niet een geheim noodnummer voor dit soort situaties?
Gelijk alles plat gooien, dat moet toch anders kunnen?

Het werkt niet snel genoeg, en in crisissituaties gaan mensen zo'n nummer vergeten of vergeten ze waar hij is opgeslagen. Menselijk gedrag in stresvolle situaties die niet continue getrained worden is gewoon ontzettend suboptimaal en leidt tot fouten.

In de luchtvaart en het spoor is veiligheid een absolute randvoorwaarde: als iets niet veilig kan gebeurt het gewoon niet. Want als er wat water in de wijn kan als het even tegenzit dan weet iedereen waar dat eindigt. En dus kiezen we altijd de veilige optie.

Dus nu ook: je kunt niet garanderen dat bij situaties adequaat gehandeld wordt, dus gaan we niet rijden. Een vliegtuig mag ook niet opstijgen als de radio's niet voldoende redundant zijn.

[SBAUKfBnS]

Als gepensioneerd machinist(Thalys) kan ik hierover zeggen. Als er problemen waren met de Telerail gebruikte wij onze mobiele diensttelefoon. Voor zover ik weet heeft nu iedere NS machinist ook een mobiele diensttelefoon. Dus waarom gelijk het hele treinverkeer plat leggen. En ja, wissels en seinen werken gewoon. Dus.....

[Rataplan_]

Het treinsysteem van Japan wordt her en der geroemd om zijn stiptheid en betrouwbaarheid. Is dat nou zó fundamenteel anders van opzet daar allemaal? Kennen ze daar ook dit soort problemen of gaan ze er daar wat serieuzer mee om?
Begrijp me niet verkeerd, als IT'er ben ik me er wel van bewust dat je zelfs met ogenschijnlijk voldoende redundancy altijd nog de wet van Murphy hebt die toe kan slaan. Maar toch bekruipt me het idee dat hier de juiste mensen wegbezuinigd zijn oid.

[lilmonkey]

Het treinsysteem van Japan wordt her en der geroemd om zijn stiptheid en betrouwbaarheid. Is dat nou zó fundamenteel anders van opzet daar allemaal? Kennen ze daar ook dit soort problemen of gaan ze er daar wat serieuzer mee om?

Nederland staat op nummertje 3 in de wereld qua punctualiteit, na Japan en Zwitserland, dus het idee dat het fundamenteel slecht(er) geregeld is hier is een beetje vergezocht. Zeker als je je daarbij bedenkt dat we hier te kampen hebben met het drukste spoorwegnet ter wereld.

[Knobby]

nou die stiptheidscijfers moet je met een flinke bak zout nemen. NS heeft gewoon als SOP om een trein geheel uit te laten vallen wanneer deze teveel vertraging heeft, want uitgevallen treinen tellen niet in de stiptheidscijfers waar de overheid hun prestaties op toetst.

[CyBeR]

En jij denkt dat uitval van treinen geen onderdeel is van de prestatiecijfers? Dan zou NS beter gewoon alle treinen uit laten vallen. 100% punctualiteit.

[Cyberpuppy]

Of anders. Trein rijdt keurig op tijd weg en stopt een paar meter na het station. Dan is hij volgens de regels op tijd vertrokken.

[Frame164]

Maar de praktijk is gewoon dat het hier vrijwel net zo goed is als in Zwitserland. En als je dan ook nog eens de extra drukte op ons spoorwegennet meeneemt in de overweging dan is het waarschijnlijk net zo goed. Ik heb in Zwitserland ook vaak genoeg vertragingen gehad door storingen.

[lilmonkey]

Sinds een aantal jaar is dit niet meer het geval. De leidende statistiek is nu 'reizigerspunctualiteit' (waar uitvallende treinen wél meetellen) en niet 'treinpunctualiteit'.

[Gast Gebruiker]

En is dat een probleem dan? Als ik van Utrecht naar Amsterdam moet, gaat er om de 6 minuten een trein. Worst case scenario is in principe 30 minuten vertraging in heel Nederland. Dus het heeft dus zo goed als geen toegevoegde waarde om vertraagde treinen door te laten rijden.

[J_van_Ekris]

Doen ze in Zwitserland ook is mijn ervaring. Toen ik voor de zwitsers spoorwegen werkte moest ik regelmatig van Bern (hoofdkantoor) naar Olten (hoofd verkeersleidingspost) en ik ben nog nooit op tijd geweest. Nadeel: de volgende trein komt soms pas over twee uur (want zo dun is de dienstregeling daar soms). Voordeel: de zwitsers doen niet zo opgefokt als de Nederlanders.

[Reactie gewijzigd door J_van_Ekris op 28 juli 2024 10:31]

[gekeren]

Ik heb een tijdje in Bern gewoond. Wat je zegt over de frequentie tussen Bern en Olten klopt dus echt niet!
Iedereen die dat wil kan dat eenvoudig controleren op sbb.ch

[J_van_Ekris]

Mijn opmerking sloeg op de tijdigheid van die verbinding. De frequentie sloeg eerder op andere delen van het net, waar we in Nederland volgens mij zelfs als eis minimaal een half-uurs dienstregeling handhaven, zit je daar in uithoeken met een veel dunnere dienstregeling.

[mutmong]

Haha, klinkt als 'manipulatie' op z'n Belgisch. 5 minuten vertraging zijn in België ook geen vertraging, ook niet als je daardoor je overstap kwijt bent.

[batjes]

Japan is al een paar keer bij de NS komen kijken om te zien hoe vernuft ons spoornetwerk is en hoe we het in hemelsnaam allemaal voor elkaar krijgen.

Japan's netwerk is veel makkelijker, bijna elke lijn daar heeft zijn eigen dedicated spoor. Terwijl hier alleen een paar boemeltjes hun eigen spoor hebben. Wij rammen op sommige delen een tiental lijnen over een handje vol sporen heen of hebben wij van die enkel spoortjes zoals Zwolle - Wierden waar tijdens spitsuur gewoon 4 treinen per uur elke richting op rijden.

We zeuren veel over de NS en Prorail, maar ons spoornetwerk is het beste ter wereld. De punctualiteit die we weten te bereiken met ons complexe en overbelaste netwerk is indrukwekkend.

[kodak]

We zeuren veel over de NS en Prorail, maar ons spoornetwerk is het beste ter wereld. De punctualiteit die we weten te bereiken met ons complexe en overbelaste netwerk is indrukwekkend.

Dat je een van de beste bent wil niet zeggen dat deze storing dus maar acceptabel is. Net zo min als dat je het indrukwekkend kan noemen een reden kan zijn om klagen maar zeuren te noemen. Als het er bij een landelijke storing vooral om gaat of het in het algemeen indrukwekkend of de beste is dan ben je waarschijnlijk niet bezig met het voorkomen en verhelpen van een storing en je klanten. Daarbij is de complexiteit niet zomaar redelijk om als argument op te voeren, zeker niet als dat ondertussen een landelijke storing en complexiteit kennelijk ontstaat door een enkelvoudig punt waar dat allemaal van afhankelijk lijkt.

En om te stellen dat het Japanse netwerk veel makkelijker is hangt er vanaf waar je naar kijkt. Wij hoeven hier geen ingewikkelde systemen te laten ontwikkelen en onderhouden om te voorkomen dat treinen bij een aardbeving ontsporen omdat de rails niet te vertrouwen is. En het is hier ook geen schande als je een paar seconden te laat vertrekt of een paar seconden te laat aan komt. En die mogelijke vertragingen nemen we wel heel ruim, kennelijk tot in uren en soms dagen.

[tweazer]

Japan's netwerk is veel makkelijker, bijna elke lijn daar heeft zijn eigen dedicated spoor.

Hier wordt gesproken over punctualiteit, in Japan hebben ze aardbevingen en hogere snelheidslijnen.
Ik weet (of het wordt niet gepubliceerd) van geen dodelijk spoorwegongeluk met een gehele trein de afgelopen tig jaar. Dat is in Japan wel wat anders ...

[Anoniem: 486069]

Voor zover is dat een treinsysteem zonder spoorweg overgangen, waar alleen de (hoge snelheids) personentrein rijdt. Dat systeem zal ongetwijfeld nog steeds complex zijn, maar bij lange na niet zo complex als het spoorsysteem hier.

[djiwie]

Japan heeft ook gewoon overwegen en "ouderwetse" treinen. Wat we vooral van de Japanners kunnen leren is hoe zij omgaan met complexiteit, zij proberen de basis zo simpel mogelijk te houden en dat helpt met oplossen van problemen na een storing. In Nederland zie je dat een storing nog uren door kan ebben nadat het opgelost is omdat alle treinen en personeel op de verkeerde plek staat. In Japan gaan ze daarna weer door met op-en-neer rijden en is de vertraging sneller ingelopen, omdat ze een minder complexe dienstregeling maken (minder afhankelijkheden van andere lijnen).

[William_H]

In mei was het trouwens ook Inntel dat op ze reet ging, en ook niet GSM-R.
Misschien dat de redacteur even de zoekfunctie kan gebruiken hier op Tweakers.
Dus de tweede keer in een jaar dat hetzelfde systeem op z'n reet gaat. En feitelijk dezelfde oorzaak, een switch naar het backupsysteem die niet goed gaat. Blijkbaar heeft die update die beloofd was niet z'n werk gedaan.

[kodak]

Ik zou dan eerder de vraag stellen of de geleerde lessen van de vorige keer al doorgevoerd waren en als dat zo is of die van invloed waren op deze storing.

[mutsje]

Zou de leasons learned nu zijn we moeten de backups vaker testen in verband met redundancy? Lijkt me wel lastig voor de beheerders die het systeem onderhouden.

[SilentDecode]

Lijkt me wel lastig voor de beheerders die het systeem onderhouden.

Als dat lastig is, doen ze hun werk niet goed. Ik ben zelf ook beheerder, dus als er iets onderuit gaat, dan zou alles fatsoenlijk, met wat latency hier en daar, door moeten kunnen lopen.

[Frame164]

Hoe groot is jouw netwerk?

[SilentDecode]

Ik heb het niet over mijn netwerk hé.. Mijn netwerk is 1 servertje. Als dat down ligt, dan ligt dat maar down.

[J_van_Ekris]

Als dat lastig is, doen ze hun werk niet goed.

Dus jij trekt regelmatig de hoofdzekeringen uit de inkomende voedingslijnen en gaat dan met het hele bedrijf in 24x7 operatie door het donker om te kijken of je no-break/NSA echt inkomen? Want dat moet je dan ook doen.

[xxs]

Om daar nou het hele treinverkeer voor stil te leggen… ze kunnen toch ook nog via het normale 3/4/5G netwerk bellen voor het geval er een incident plaats vindt?

[Ascension]

Lees even de bijdragen door van @EDIT in het vorige draadje betreffende dit onderwerp.

[robert_paats]

Probleem was niet het GSM-R netwerk maar een telefonie systeem daar achter.
Dus omschakelen zal vermoedelijk niet veel nut hebben omdat ze dan nog steeds gebruik moeten maken van dat telefonie systeem maar dan achter het publieke GSM netwerk.

Telecom storingen zijn meestal behoorlijk complex en worden alleen snel opgelost als daarin van te voren in is voorzien. En dat hadden ze blijkbaar gezien de redundante systemen.
Alleen die redundantie werkte niet!

[Frame164]

Dat ze dat zelf niet bedacht hebben zeg. Of is jouw oplossing misschien toch een beetje te simpel?

[xxs]

Zoals ik het begrijp hebben ze een INTtel en een GSM-R netwerk, dat zijn eigen netwerken en niet publiekelijk bereikbaar. Het INTtel systeem, wat kennelijk gebruikt wordt om te communiceren tussen verkeersleiding en machinist, had in dit geval een storing. "Tringg Jan ik sta stil bij paal 911 maar dat had je natuurlijk al gezien?" Die communicatie was niet mogelijk, alle andere systemen werkten wel. Dan vraag ik me af waarom hij zijn eigen mobieltje niet pakt en via het publieke net van Vodafone/KPN whatever Jan even belt om te zeggen dat hij stil staat bij paal 911 wat Jan waarschijnlijk al gezien had omdat alle andere systemen wel werkten.

Simpel, ja vast wel maar leg jij het dan maar eens beter uit waarom dat niet zou kunnen of waar ik fout ga.

[mutmong]

..en als er nul ontvangst is bij publieke netwerken net waar de machinist zich bevindt?...

[xxs]

Tja, als de backup van de backup van de backup van de backup het niet meer doet én je heb toevallig ook geen dekking in het publieke net dan heb je natuurlijk een punt. Vliegtuigen hebben minder ingebouwde veiligheden.

[Soldaatje]

Te simpel bestaat niet, het kan niet simpel genoeg zijn. KISS-principe.

[willemblans]

Ja nou ik wel, als er blaadjes op de rails liggen, of het vriest zijn er problemen, alleen hier, toch ook niet in Zwitserland bv. zo kan je nog 100 gevallen aanhalen, wij hadden het hier vroeger ook niet!! Ging alles perfect, wie is dan de schuldige??

[wildhagen]

De problemen bij vorst/sneeuwval, en blaadjes op de rails, spelen in alle landen. Echt geen uniek Nederlands probleem ofzo. Afgelopen winter heeft zowel in Duitsland als Zwitserland als Oostenrijk het treinverkeer dagenlang forse overlast gehad van sneeuwval bijvoorbeeld.

Dat je daar in Nederland weinig van meekrijgt, is omdat dat de media hier niet haalt. Net zoals een storing in Nederland de media in die landen niet snel zal halen.

Daarnaast is de overlast van bladeren op de rails de laatste jaren al flink teruggedrongen, nu ze Sandite-treinen laten rijden daarvoor.

[Frame164]

Vroeger hadden we die problemen niet omdat er toen veel minder treinen reden. Als een trein dan een keer een paar minuten vertraging had door natuuromstandigheden dan haalde je dat wel weer in. Maar met de huidige hoeveelheid treinverkeer werkt een paar minuten vertraging gelijk door in de hele dienstregeling.

En Zwitserland is ook verre van perfect. Sommige delen zijn wat beter maar je betaalt dan ook 2x zoveel voor een treinkaartje. Als de NS de prijzen zou verdubbelen kan er ook een stuk meer.

Vergeleken met onze buurlanden (die kwa bevolkingsdichtheid en klimaat het meest vergelijkbaar zijn) scoort de NS/Prorail extreem hoog.

En bekijk een willekeurig expat filmpje op Youtube en vrijwel iedereen is extreem positief over ons openbaar vervoer.

[Reactie gewijzigd door Frame164 op 28 juli 2024 10:31]

[Ascension]

<verkeerde antwoord>

[Reactie gewijzigd door Ascension op 28 juli 2024 10:31]

[willemblans]

We lopen nog steeds een heeeeel stuk achter, waarom gebeurd dit nooit in bv China

[wildhagen]

Jij denkt echt dat storingen alleen in Nederland optreden, en nooit in andere landen (of dat nou China, Japan, Duitsland, etc is)?

Echt, ik kan je garanderen dat het daar ook gewoon gebeurt. Alleen haalt het de Nederlandse media doorgaans niet, net als een Nederlandse storing de media in China of Japan niet zal halen.

Overall behoort het Nederlandse netwerk, en de punctualiteit ervan, nog altijd tot de wereldtop, als je meerekent dat we één van de drukstbereden spoornetten van de wereld hebben.

[Gluten Parody]

In Japan zijn nog wel eens aardbevingen, dan gaat er weer van alles stuk en staan de Maglevs stil.

[Danos9786]

Zou China dit überhaupt delen? En volgen wij nou echt wat er in China gebeurd als daar in een regio de treinen niet rijden?

[willemblans]

Ze delen echt alles.

[Danos9786]

En is het ook wel betrouwbaar?

[joneboon]

Waar kan ik de gemaakte km met de auto declareren?

[Frame164]

Dat zou in de SLA moeten staan die je met de NS hebt afgesproken. (maar ik lees altijd van mensen die met de auto gaan dat ze de trein veel te duur vinden, dus je zou geld over moeten hebben gehouden door met de auto te gaan).

[Reactie gewijzigd door Frame164 op 28 juli 2024 10:31]

[J_van_Ekris]

De NS zorgt er voor dat je thuis komt, of biedt je een overnachting aan. Ik ben regelmatig door een NS-medewerker in een taxi gezet met de opmerking dat chauffeur de rekening rechtstreeks naar de NS kon sturen.

[joneboon]

Beetje een late reactie, maar snap je punt en ga er ook van uit dat ze uiteindelijk iets regelen. In dit geval had ik m’n vriendin opgehaald bij een station, want er waren nog andere afspraken… Ik ben van mening dat dit probleem voorkomen had kunnen worden. Denk dat bedrijven soms te makkelijk wegkomen met storingen her en der. Misschien als er een soort van boete komt dat ze meer tijd en moeite stoppen in het onderhouden van hun systemen.

[J_van_Ekris]

Allereerst, ik snap gewoon dat je baalt net als iedereen. Het is gewoon waardeloos als je naar huis wil en je reis van 2 uur wordt ineens drie keer zo lang (gebeurde mij helaas regelmatig).

Ik ben van mening dat dit probleem voorkomen had kunnen worden.

Ik zit professioneel in extreem hoog-beschikbare omgevingen, en ik moet je teleurstellen. Er zijn altijd dingen die je niet kunt voorkomen, of alleen tegen krankzinnige kosten. Zelfs als falen levens kost, accepteert de overheid een risico omdat het anders onbetaalbaar wordt.

Denk dat bedrijven soms te makkelijk wegkomen met storingen her en der. Misschien als er een soort van boete komt dat ze meer tijd en moeite stoppen in het onderhouden van hun systemen.

Varieert enorm van organisatie tot organisatie. In heel veel gevallen zie je dat mensen verwend worden met een enorm hoge beschikbaarheid en dan schrikken als je een serie storingen krijgt. Het lijkt vaak zo makkelijk van buitenaf, terwijl het dagelijks vaak enorm hard werken is om die verwachting waar te maken.

Boetes helpt niet: het gaat alleen maar ten koste van de investeringen die men moet doen om de boel aan de gang te houden. Het zijn vaak kapitaalintensieve industrieeen, dus een boete wordt of niet gevoeld, of gaat ten koste van de volgende verbetering.

Het Nederlandse spoor is zo krankzinnig druk en met zoveel randvoorwaarden omgeven (energieverbruik, arbeidsduur, opleidingseisen, veiligheid, geluidsoverlast, etc..), dat als er ergens iets serieus misgaat er een onplanbare puinhoop ontstaat die je niet meer gestart kan worden. Dat krijg je als je de grens opzoekt van je capaciteit: je hebt geen slack meer om tegenslagen op te vangen.

[Reactie gewijzigd door J_van_Ekris op 28 juli 2024 10:31]

[Anoniem: 85014]

Backups die niet getest worden, bestaan niet (of zullen niet werken)

[xxs]

Een backup is pas een backup als deze ook werkt/getest is. Anders is het geen backup. 😜