fbpx

ProRail: Meer treinen mogelijk door uitbreiding planning software

klok 19 feb 2020 7:19

Vanaf dienstregeling 2022 kunnen treinen sneller na elkaar vertrekken en aankomen. Daardoor ontstaat er meer capaciteit op het spoor, waardoor er meer treinen kunnen gaan rijden. Dat bevestigt ProRail na een bericht van de Telegraaf.

Nieuwe normen

Nu wordt er minimaal drie minuten tussen twee treinen gepland. Maar die generieke norm houdt geen rekening met de plaatselijke situatie. Een verbeterde module in de huidige software moet ervoor zorgen dat dit kan gaan veranderen. Straks zal per locatie, en zelfs per trein de minimale opvolgtijd tussen twee treinen gaan verschillen. “Er is straks geen sprake meer van een generieke norm”, legt ProRail-woordvoerder Andy Wiemer uit. Wiemer vertelt verder: “We weten dat er situaties zijn waarin de norm van 3 minuten die we nu hanteren veel te ruim is.”

Van 7.000 naar 9.000 treinen

Voor het ontwerp van de dienstregeling 2022 zal de verbeterde software gebruikt worden. Doordat treinen elkaar op sommige plekken sneller kunnen opvolgen dan nu het geval is, ontstaat er ruimte op het spoor voor meer treinen. In de Telegraaf legt Niels Bik van ProRail uit dat de capaciteit op het Nederlandse spoor hierdoor zal groeien van 7.000 naar straks 9.000 treinen.

Kinderschoenen

De spoorsector ontwerpt de dienstregeling in Donna. Bij NS en ProRail is er een speciaal team ingericht die uitsluitend werken om deze software te verbeteren. De software zal straks op microniveau (sectieniveau) de dienstregeling gaan doorrekenen. “Dat gaat in de praktijk om miljoenen secties die we in een milliseconde door moeten gaan rekenen. Dat vergt vergt enorme rekenkracht”, aldus Bik. Hij wijst er wel op dat de ontwikkeling nieuw is. “Dat staat echt nog in de kinderschoenen.”

37 gedachten over “ProRail: Meer treinen mogelijk door uitbreiding planning software”

  1. Tjeerd schreef:

    Lijkt me een goede ontwikkeling. Inderdaad is 3 minuten soms wel erg ruim en meer capaciteit gaat zejer in de spits helpen.

    @redactie, laatste alinea: “Dat vergt vergt enorme rekenkracht”, lijkt me een foutje. 😉

    1. Tjeerd schreef:

      Ha! Maak ik zelf ook typefout. Wie met één vinger naar een ander wijst…

  2. dries molenaar schreef:

    Jonge, jonge, daar komen ze na al die jaren mee. Het is een ontwerpfout/beslissing van jaren terug en de reparatie moet nu als innovatie in de vitrine. Zijn er nog meer van die dingen?

    1. dries molenaar schreef:

      NB men zal wel op eigen hardware willen draaien. In de cloud kun je software laten draain met 3000 cores, als het ware. Daar kun je met je eigen zootje niet tegen op.

      1. Ricardo schreef:

        Tot de rekening op de mat valt, want puur dingen in “de cloud” draaien is vaak best prijzig en de voorgestelde besparingen waar aanbieders mee schermen zijn minimaal.

        De enige besparing is namelijk dat je geen systeembeheerders meer nodig hebt, maar je hebt nog steeds mensen nodig die jouw stukje van de cloud goed inrichten, je hebt nog steeds functioneel beheerders en ontwikkelaars nodig voor de applicaties die je in de cloud wil draaien en als het tegenzit moet je ook nog eens de software compleet herschrijven omdat het simpelweg een grote applicatie is in plaats van allerlei losse stukken.

  3. Rudy schreef:

    Dit gaat niet werken. Op papier is dit leuk, maar de praktijk zal het achterhalen. Natuurlijk, als er geen verstoringen zijn, dan zal de capaciteit toenemen. De prijs die daarvoor betaald wordt is een regelmatige totale crash-down van het netwerk. Dit is een algemene wijsheid die al jaren bekend is uit communicatie netwerken. Je kan de feitelijke capaciteit tegen de theoretische capaciteit aan drukken maar daardoor wordt het netwerk instabiel.

    Het enige wat helpt is meer capaciteit op de gevoelige plekken. Dit betekent meer wissel en meer uitwijksporen.

    Ik ben er wel van overtuigd dat de software alternatieve oplossingen kan vinden waaraan de menselijke planner niet heeft gedacht. Verder zou de software gebruikt moeten worden om de stabiliteit van het netwerk te simuleren. Dus bepalen of een kleine verstoring vanzelf verdwijnt of aanleiding is tot een grote verstoring.

    1. Ricardo schreef:

      Eens, het steeds verder vol plannen van het spoor zal bij verstoringen steeds grotere gevolgen hebben, maar als vanuit de overheid het budget niet komt om de capaciteit structureel uit te breiden, moet ProRail naar dit soort lapmiddelen grijpen…

      1. Johan schreef:

        Prorail kan moeilijk de overheid de schuld geven zolang ze grote delen van het budget besteden aan het weghalen van wissels in plaats van het aanleggen van nieuwe wissels, dus aan het reduceren van de uitwijkmogelijkheiden in plaats van aan het uitbreiden ervan.

        1. Ricardo schreef:

          Maar aan de andere kant is een wissel ook iets dat meer kans op verstoring geeft, dus daar zal een afweging gemaakt moeten worden. Moeten er altijd maar wissels liggen van de ene kant van het station naar de andere kant, waarbij soms rare routes ontstaan/dure onderdelen nodig zijn om het maar passend te krijgen, of is het kunnen bereiken van de naastgelegen sporen goed genoeg? Moet ieder station maar de mogelijkheid hebben om via het andere spoor een trein voorbij te gaan, alleen maar voor het geval er een defecte trein zou staan?

          Wat mij betreft hoeft dat niet, want ik verwacht dat zowel kans op als impact van een verstoring van zo een “overbodige” wissel groter zal zijn dan het verlichten/verhelpen van andere verstoringen door een uitwijkmogelijkheid te bieden. Maar dat is een lastig argument, want gevoel en cijfers botsen dan met elkaar.

    2. Rudy schreef:

      Ik heb er nog eens over nagedacht. Het probleem is geen software probleem maar een modelleringsprobleem. Dat wil zeggen dat nieuwe theorieën ontwikkeld moeten worden. Wat nodig is, is een soort statistische netwerkanalyse. Bijvoorbeeld, hoe lang duurt het voordat een trein vertrekt na een groen tonend sein. Meestal vertrekt de trein direct, maar soms duurt het 3 minuten. Of wat is de rijdtijdsdistributie over een traject. Er is heel veel theorievorming nodig. Met een goede theorievorming kan onderscheid gemaakt worden tussen een kwetsbare en een robuuste dienstregeling.

      Ik zag dat men met “scrum” werkt. Ik noem scrum smalend “pluk het laag hangende fruit eerst”. Dat wil zeggen dat ze snel eerste goede resultaten krijgen tegen lage kosten, maar als theorievorming en architectuur nodig zijn, dan faalt scrum geheel.

  4. JanN schreef:

    Kan zo’n planning ook op enkel spoor worden toegepast of is dat uit den boze.

    1. dries molenaar schreef:

      Hoezo? Het gaat gewoon om bezet of vrij spoor. De rijrichting van de treinen doet er niet toe.

    2. Jan H schreef:

      Ik denk niet dat de huidige 3 minuten daar betrekking op hebben. Het komt immers op veel enkelsporige plekken voor dat bij een station waar twee treinen elkaar kruisen, ze beide weer verder rijden over een stuk spoor waar 1 minuut geleden nog een andere trein reed.

  5. Rene.C de Groot schreef:

    En de energie voorziening op de bovenleiding ,kan die dat wel aan?

    1. FyraFlop34 schreef:

      Op termijn wil ProRail af van de 1.5 kV die nu wordt gebruikt, maar dat is iets voor de relatief verre toekomst.

  6. Treintjes schreef:

    Beter is om met name in de Randstad meer spoorcapaciteit te creëren, belangrijk om de te verwachte groei veilig te kunnen verwerken.

    1. Papias schreef:

      Niet alleen de randstad. Wat dacht je van Arnhem-Utrecht en Groningen-Zwolle? Dat zijn drukke trajecten buiten de Randstad.

    2. Jo schreef:

      Van wat ik begrijp liggen de punten waar dit echt een verandering zou brengen juist buiten de randstad. Er zijn punten waar het treinverkeer ernstig wordt verontregeld op grotere stukken als treinen niet exact op tijd rijden omdat meerdere treinen op 3 minuten afstand van elkaar rijden. In de regio van Breda, Tilburg, Zwolle, Arnhem, Amsterdam en Hengelo zou deze verandering grote verbeteringen met zich mee brengen. Enkel Amsterdam van die plaatsen ligt in de randstad. Het punt is dat er belangrijke knooppunten zijn zoals Zwolle en Breda waarbij treinen op korte trajecten op hetzelfde spoor dicht op elkaar rijden en waarbij gecondenseerd spoorgebruik dit kan versnellen. In de randstad is er vaak meer spoorcapaciteit om dit op te vangen.

  7. Dominic schreef:

    Nu laat de software het dus al toe dat er iedere drie minuten een trein in dezelfde richting vertrekt. Dit betekent dus nu al dat er 20 treinen per uur per richting kunnen vertrekken. Nu ben ik geen expert maar in ons kleine landje met alleen maar kleine steden is dit toch meer dan voldoende? Ik geloof nooit dat er nu al een traject is waar zoveel treinen rijden. Bovendien, zelfs op de drukste trajecten zijn 10 treinen per uur toch wel voldoende zeker?

    1. anton schreef:

      elke 3 minuten betekend alleen 20 treinen per uur als het aanbod homogeen is. Arnhem-Elst-Nijmegen zit nu al (bijna) vol met 12 reizigerstreinen per uur. De sprinter vertrek direct achter de iC en komt aan net voor de volgende IC.

      1. Treinreiziger.nl (Hildebrand) schreef:

        Het is wat Anton zegt: omdat er intercity’s en sprinters op hetzelfde spoor rijden, kunnen er veel minder treinen dan 20 per uur rijden. Rotterdam – Delft / Rijswijk is ook goed benut.

    2. Johan schreef:

      Het kan bijvoorbeeld van pas komen in Zwolle. Nu heb je na de knoop richting het noorden

      .15/.45 IC Groningen
      .18/.48 IC Leeuwarden
      .21/.51 St Emmen
      .24/.54 Spr Groningen

      en richting de IJsselbrug

      .17/.47 IC Den Haag
      .20/.50 IC Rotterdam
      .23/.53 Spr Utrecht

      Die drie minuten er steeds tussen is vanwege dit soort normtijden. Voorheen zat de sprinter naar Amsterdam er ook nog tussen, waardoor ook de laatstgenoemde optocht nog 3 minuten langer duurde. Met 9 minuten tussen het vertrek (en trouwens ook de aankomst) van de eerste en de laatste trein gaat het voordeel van een knoop natuurlijk grotendeels verloren.

      1. lezer schreef:

        Zwolle krijgt wel ‘Herfte’ erbij over een paar jaar. Ik stel me zo voor dat de treinen van en naar Emmen hierdoor parallel kunnen rijden met de trein van en naar Meppel.

        1. Johan schreef:

          Ja, maar Zwolle krijgt geen tweede IJsselbrug. Bovendien zou er dan een sprinter naar Leeuwarden bijkomen.

  8. Tonny Schonewille schreef:

    Inderdaad een onzinmaatregel die alleen maar de problemen dempt die het gevolg zijn van een gebrek aan investeringen.

    1. Hildebrand treinreiziger.nl schreef:

      Elk jaar wordt er circa 3 miljard geïnvesteerd in het spoor. Graag zou ik ook meer spoorverdubbeling zien en nieuwe spoorlijnen. Ik zou het geen onzin maatregel willen noemen. Kijk maar eens naar het voorbeeld van Johan. Nu staan ze te wachten voordat ze Zwolle uit mogen. Wel belangrijk is dat het wel betrouwbaar blijft, dus te dicht opvolgen brengt ook weer risico’s mee.

      1. Tonny Schonewille schreef:

        Je hebt wel gelijk, ik overdrijf een beetje. Maat ik zie in de praktijk wel weinig terug van die 3 miljard aan investeringen. Misschien ook niet helemaal eerlijk omdat sommige dingen (PHS) voor mij negatief uitvallen. Dus het is meer een gevoel van geld op verkeerde dingen in zetten.

        1. FyraFlop34 schreef:

          Het meeste van dit geld wordt ongetwijfeld geïnvesteerd in het onderhoud en het veiliger maken van het spoor. Zeker met om de drie minuten een trein zullen de sporen (nog) vaker gecontroleerd moeten worden. ProRail moet ook bewaakte overgangen aanleggen, hekken naast sporen plaatsen, wissels vervangen…

        2. Tonny Schonewille schreef:

          Onderhoud is wat mij betreft toch echt iets anders dan investeren. Maargoed op die manier klinkt alles wel mooier.

  9. Oscar schreef:

    Ik heb al die tijd gedacht dat die 3 minuten een beperking was van de ATB. Lees: korter dan 3 minuten op elkaar, dat trekt de ATB niet. Op basis daarvan leek mij de vervanging van ATB door ERTMS Level 2 logisch. Maar nu blijkt het dus een limiet te zijn van de planningssoftware.

    Ik heb ook zitten denken dat die 3 minuten waren gebaseerd op de langste remtijd (waarschijnlijk die van een 5000 ton ertstrein met 3x 6400 bij 80 km/u). Dan had de switch naar ERTMS ertoe geleid dat de opvolgtijd treinafhankelijk was geworden.

    Het loslaten van de 3 minutennorm is uiteraard goed nieuws. In theorie kan in Houten Castellum de sprinter naar Geldermalsen al vertrekken zodra de laatste as van de intercity het invoegwissel is gepasseerd (en het betreffende wissel in de afbuigende stand is gezet). Het heeft geen zin om drie minuten te wachten; de kans dat de sprinter vóór Geldermalsen (inhaalpunt) alsnog binnen remwegafstand van de IC komt, is klein. Omdat de sprinter dezelfde vmax als de IC heeft, is die kans zelfs heel klein… 😉

    1. Treinreiziger.nl (Hildebrand) schreef:

      Met ERTMS kunnen treinen inderdaad dichter opvolgen. Nu is het zo dat de grote van seinblokken bepalen hoe snel treinen elkaar kunnen opvolgen. Nu er in secondes gepland wordt, is er ook meer mogelijk, en kun je bijvoorbeeld ook uitgaan van 140 seconde opvolgtijd. De norm moet ook rekeninghouden met betrouwbaarheid. Je wil voorkomen dat treinen dat treinen onnodig rood of geel sein krijgen, dus moet de opvolging ook niet te strak zijn.

    2. Johan schreef:

      Enerzijds heb je seinblokken die de *afstand* tussen treinen bewaken. Anderzijds heb je normtijden voor de *tijd* tussen twee treinen met een conflicterende beweging. Als de laatstgenoemde vervalt, wordt de eerstgenoemde natuurlijk de beperkende factor, tenminste als je het hebt over treinen die achter elkaar aan rijden. De normtijden hebben namelijk niet alleen betrekking op “invoegen”, maar ook bijvoorbeeld op gelijkvloers kruisen.

  10. Lezer schreef:

    Interessant, mooie ontwikkeling.

    @Redactie, wel een taalfout in de kop: planningsoftware is één woord (software is namelijk géén bijvoeglijk naamwoord, dus moet het aan elkaar geschreven worden).

  11. Annemiek schreef:

    Grappig dat gepoch met dat ‘ingewikkelde’ doorrekenen van de dienstregeling. Zo moeilijk is dat ook weer niet. Een aantal decennia geleden bedachten ze de basisdienstregeling zoals die nu nog deels bestaat, met grote rollen papier, een liniaal en een potlood. Uit die tijd stamt ook de veiligheidsmarge van drie minuten, die door sommige kenners een ‘ontwerpfout/beslissing van jaren terug’ wordt genoemd. Dat er straks duizenden berekeningen per milliseconde gemaakt moeten worden (wat een gewone huis-, tuin- en keukenprocessor gewoon kan) is niets bijzonders. Er is niemand die er last van heeft als het een paar uurtjes (of een nachtje) duurt om de dienstregeling door te rekenen. Kansloos gewauwel dus van Niels Bik van Prorail.

    1. Annemiek schreef:

      Waar veel winst valt te halen in de dienstregeling, is een overstap op eenmansbediening. De taken van de conducteur in de vertrekprocedure kunnen dan worden geschrapt. De vertrekprocedure kan dan door de machinist worden gestart op commando van de treindienstleider en zal veel consequenter verlopen dan wanneer een conducteur (ten koste van de dienstregeling) respijt kan verlenen aan een ieder die er nog aan komt rennen. Net als bijvoorbeeld in Engeland, kan de machinist de situatie op het perron dan volgen via monitors. Het moet niet al te moeilijk zijn om de beelden zichtbaar te maken in de cabine van de machinist.

  12. Richy schreef:

    Volgens mij moeten er gewoon meer sporen neergelegd worden om vertragingen ed. op te vangen. Om de opvolgtijden te versnellen met zogenaamde slimme software klinkt allemaal leuk, maar in de praktijk als er een foutje of verstoring optreedt loopt de hele boel gelijk mega in de soep. Het wordt volgens mij alleen robuuster met meer sporen, nieuwe lijnen en uitbreidingen komen. Sporen weghalen zoals in Naarden-Bussum lijkt me niet slim, er kunnen beter 2 sporen toegevoegd worden.

    1. Simon schreef:

      Mee eens, treinen hebben tijd nodig om een station te verlaten. Een wisselstraat is geen flipperkast.
      Er zal best ruimte zijn voor verbetering, maar die krappe marges maken de kans op verstoring steeds groter en veilig werken ingewikkeld.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd.