OV in Nederland

Treinverkeer rond Utrecht Centraal ligt plat
Geplaatst op: vrijdag 18 januari 2013 16:08
Laatst bijgewerkt: vrijdag 18 januari 2013 16:09

Het treinverkeer van en naar Utrecht Centraal ligt vrijdagmiddag plat door een storing in het systeem om seinen en wissels te bedienen.

Dat melden NS en Prorail.

Er is dus geen treinverkeer mogelijk in de avondspits. Ook van en naar Gouda rijden geen treinen door eenzelfde storing
Lees verder | Dossier Storingen in de treindienst | Meer nieuws over Storingen in de treindienst

Inmiddels rijden er wel weer wat treinen, volgens de storingsinformatie.

Vanaf Utrecht rijd momenteel wel weer wat naar Overvecht, Breukelen en Bunnik, maar Woerden ligt nog wel plat. Verstoring lijkt zich verplaatst te hebben naar Woerden/Gouda als ik het kaartje zo moet geloven.

Ook daar lijkt nu weer wat te rijden, alleen tussen Rotterdam en Utrecht en tussen Leiden en Utrecht is het nog bal.

Ja maatschappij voor beter OV. Hier word je toch weer met je neus op de feiten gedrukt. Hieruit blijkt dus gewoon weer dat het met deze omstandigheden onmogelijk is door te rijden met de normale dienstregeling.

Wat heeft een reguliere grote verstoring te maken met wel of geen winterdienst rijden? :')

JeffreyMeijer schreef:Ja maatschappij voor beter OV. Hier word je toch weer met je neus op de feiten gedrukt. Hieruit blijkt dus gewoon weer dat het met deze omstandigheden onmogelijk is door te rijden met de normale dienstregeling.

wut?

Waar blijft het backupsysteem?

Dat wordt al enige tijd getest. Afgelopen weekend heeft men op proef de verkeersleiding van Amsterdam op een backup-werkplek in Utrecht overgenomen en die proef lijkt geslaagd. Alleen, zelfs met een backupsysteem heb je niet het systeem binnen een paar minuten in de lucht en als je dan tien minuten niets kan doen op het belangrijkste spoorknooppunt van Nederland heb je al snel een hoop problemen die je niet in een half uurtje weer hebt opgelost.

Bee, je verkondigt onzin. High performance computing heeft hier al jaren goede oplossingen voor.

KM46 schreef:Waar blijft het backupsysteem?

Heeft gewerkt.

Thom91 schreef:

KM46 schreef:Waar blijft het backupsysteem?

Heeft gewerkt.

En waarom werkt het niet meer dan?

KM46 schreef: En waarom werkt het niet meer dan?

Hoe bedoel je?

Thom91 schreef:

KM46 schreef: En waarom werkt het niet meer dan?

Hoe bedoel je?

Je schrijft "het heeft gewerkt".

Dus ik ga er vanuit dat het niet meer fuctioneert het reservesysteem, of lees ik het verkeert?

KM46 schreef:

Thom91 schreef:

KM46 schreef: En waarom werkt het niet meer dan?

Hoe bedoel je?

Jij schrijft "het heeft gewerkt".

Dus ik ga er vanuit dat het niet meer fuctioneert het reservesysteem, of lees ik het verkeert?

Je leest het verkeerd, het back-up systeem is vanmiddag in functie getreden, bij mijn weten dan.

Mooi toch. Dat het fuctioneert waarvoor het bedoeldt is.

En ik las het verkeert .

Waar kwam die storing vandaan dan?

Volgens ProRail heeft het systeem er 10 minuten uit gelegen. De nood-VL post bemensen kost altijd meer tijd (zit op een andere locatie in Utrecht, moet opgestart/ingelogd worden omdat het alle werkplekken kan bedienen en de mensen moeten nog uit de normale post komen). Het is alleen jammer dat NS na een storing van 10 minuten 3 uur nodig heeft om weer een fatsoenlijke treindienst te kunnen rijden, maar dat is een bekend gegeven...

deadlock schreef:Bee, je verkondigt onzin. High performance computing heeft hier al jaren goede oplossingen voor.

Tuurlijk, overal zijn oplossingen voor. Echter is de systeemarchitectuur van posten die verbindingen hebben met onderposten die verbindingen hebben met wissels etc niet echt te matchen met goede IT architectuur.
Geloof me: er is kosten nog moeite gespaard voor het project om de VL-posten dubbel uit te kunnen voeren. Er wordt gesproken over 3 fases van overnemen: in fase 1 bedienen client in Utrecht de computers in Amsterdam, in fase 2 bedienen clients in Utrecht servers in Utrecht die via Amsterdam met alle beveiliging communiceren en in fase 3 (total meltdown zegmaar) bedient Utrecht alles, en is er een tweede verbinding tussen elke onderpost en Utrecht. Omdat er dus nog zoveel oude meuk tussen zit is het nog een droom om hot failovers te kunnen doen, los van het aspect dat je fysiek mensen moet verplaatsen. Er zit daarnaast nog de menselijke factor bij dat treindienstleiders in sommige dingen ook gewoon geholpen moeten worden als ze in Utrecht op een calamiteitenpost zitten - dingen werken anders, anders ingericht en sommige dingen kunnen niet.

Ik ben toch blij dat de luchtverkeersleiding niet door de NS/Prorail gerund wordt.

Het gemiddelde bedrijf kan na een "ramp" echt niet verder - een niet nader te noemen groot bekend IT bedrijf heeft bijvoorbeeld datacenters onder lekkende daken, wel een uitwijk voor de meldingscentrale, maar niemand weet hoe dat moet of hoe dat getest wordt.
Overigens is deel van de reden dat veel nog zo ouderwets is, is dat 20 jaar geleden de IT gewoon niet ver genoeg was om veilige systemen op te leveren. PLCs en Relais zijn vaak nog de norm omdat ze betrouwbaar en veilig zijn...

Een verschil tussen een treindienstleiding en luchtverkeersleiding is dat een treindienstleiding ook allerlei apparatuur zoals seinen en wissels aan zijn systemen gekoppeld heeft. In de lucht staan geen seinen op wolken en kan men in uiterste nood ook nog terugvallen op papier.

Nou als men in de luchtvaart weer terug gaat op papieren aansturing en het spreekwoordelijke spiegeleiwapperen dan is binnen no time Schiphol echt plat hoor. Ik denk dat dan hooguit 20% van het gebruikelijke vliegverkeer kan worden afgehandeld...

webguy schreef:

deadlock schreef:Bee, je verkondigt onzin. High performance computing heeft hier al jaren goede oplossingen voor.

Tuurlijk, overal zijn oplossingen voor. Echter is de systeemarchitectuur van posten die verbindingen hebben met onderposten die verbindingen hebben met wissels etc niet echt te matchen met goede IT architectuur.
Geloof me: er is kosten nog moeite gespaard voor het project om de VL-posten dubbel uit te kunnen voeren. Er wordt gesproken over 3 fases van overnemen: in fase 1 bedienen client in Utrecht de computers in Amsterdam, in fase 2 bedienen clients in Utrecht servers in Utrecht die via Amsterdam met alle beveiliging communiceren en in fase 3 (total meltdown zegmaar) bedient Utrecht alles, en is er een tweede verbinding tussen elke onderpost en Utrecht. Omdat er dus nog zoveel oude meuk tussen zit is het nog een droom om hot failovers te kunnen doen, los van het aspect dat je fysiek mensen moet verplaatsen. Er zit daarnaast nog de menselijke factor bij dat treindienstleiders in sommige dingen ook gewoon geholpen moeten worden als ze in Utrecht op een calamiteitenpost zitten - dingen werken anders, anders ingericht en sommige dingen kunnen niet.

Dat iets een verkeerde architectuur heeft betekent dus dat je het anders moet ontwerpen. Als dit zou gaan om de bediening van kernwapens had het namelijk wel gekund.