Praktijkproef Amsterdam – Netwerkmanagement van tekentafel naar operationeel bedrijf

Afgelopen maart was een mijlpaal in het prestigieuze project Praktijkproef Amsterdam: de gecoördineerde regeling op de A10 West bij Amsterdam ging live. Het is de eerste fase van het wegkantspoor van de proef, ‘operationeel opleveren voor evaluatie’. Wat is er de afgelopen twee jaar gedaan om het concept van gecoördineerd netwerkbreed verkeersmanagement van de tekentafel naar de A10 te krijgen? In deze bijdrage gaan we in op de gemaakte keuzes, de opgeleverde componenten en de lessen.

Betrouwbare reistijden en een vlotte doorstroming – het is de wens van weggebruikers en daarmee het streven van wegbeheerders. Maar hoe bereik je het? Al in 1996 werd voor het vierde kaderproject DACCORD nagedacht over de mogelijkheden van gecoördineerd netwerkbreed verkeersmanagement. De verkeerskundige theorie achter dit concept is dat er winst (= betrouwbaardere reistijden, betere doorstroming) te behalen valt door de benuttingsmaatregelen van de verschillende wegbeheerders in een regio in samenhang in te zetten.
Jarenlang was gecoördineerd netwerkbreed verkeersmanagement echter vooral een mooie belofte. Er werden weliswaar talrijke studies uitgevoerd om de meerwaarde van netwerkbreed verkeersmanagement ten opzichte van lokale regelingen aan te tonen, maar die studies waren meest theoretisch. De grote vraag was: hoe vertaal je de belofte naar de complexe praktijk van de straat? Wat voor technologieën en slimme regelsoftware heb je nodig? Hoe zit het met rekensnelheid, schaalbaarheid en de beperkingen van monitoring?

Van FileProof tot echte proef
In 2006 kwam er geld vrij om die implementatievragen te onderzoeken. Het Ministerie van (toen nog) Verkeer en Waterstaat was FileProof gestart, een groot project waarin nieuwe bereikbaarheidsideeën werden beproefd. Een van de grotere deelprojecten was ‘Verbeteren doorstroming A10’ van gemeente Amsterdam, Stadsregio Amsterdam, provincie Noord-Holland en Rijkswaterstaat. Doel was “de doorstroming bevorderen door het inzetten van gecoördineerde toeritdoseerinstallaties en aanpassingen van de bijbehorende aansluitingen en verkeersregelinstallaties”. De A10 werd uitgerust met extra toeritdoseerinstallaties en route-informatiepanelen, maar tot gecoördineerd netwerkbreed verkeersmanagement op straat kwam het nog niet. Een direct uitvloeisel van het FileProof-project was wel dat eind 2009 de Proof of Concept gereed was, een beschrijving van de gewenste opzet van een netwerkbrede praktijkproef op de A10.
Even leek het erop dat die proef een stille dood zou sterven, maar op 25 juni 2012 kwam het verlossende woord: het ministerie van Infrastructuur en Milieu besloot om de Praktijkproef Amsterdam definitief door te laten gaan. Er werd voor gekozen om het netwerkbrede verkeersmanagement in de eerste fase te laten bestaan uit een parallel ‘wegkantspoor’ en ‘in-car spoor’.
De afgelopen twee jaar hebben de gemeente Amsterdam, de stadsregio Amsterdam, de provincie Noord-Holland en Rijkswaterstaat samen met onder meer TU Delft, Arane, MARCEL, Technolution, Vialis, Fileradar en Ziut hard gewerkt aan de proef. Voor het wegkantspoor zijn alle benodigde functionele componenten gespecificeerd en ontwikkeld om in het proefgebied – zie het kaartje hiernaast – de doseerlichten van Rijkswaterstaat en verkeerslichten van gemeente Amsterdam aan elkaar te knopen. Op 14 april 2014 kon het systeem live om het wegkantdeel van netwerkbreed verkeersmanagement in de praktijk te evalueren. Hiermee is de eerste fase van de Praktijkproef afgerond.
In dit artikel gaan we nader in op de inspanningen van de laatste twee jaar voor het wegkantspoor. Na een korte bespreking van het regelconcept dat is toegepast in de Praktijkproef, staan we stil bij de verschillende functionele componenten van de proef, de voor het wegkantspoor gebruikte testomgeving en de opgeleverde analysetool. Uiteraard komen ook de lessons learnt aan de orde. We sluiten het onderwerp daarna af met een aantal ‘verdiepende’ bij-artikelen over technologie, netwerkregelingen én de vorderingen in het in-car spoor.

HET REGELCONCEPT

Voor de A10 West is een op maat gesneden regelconcept uitgewerkt. Uitgangspunt is een aantal basisoplossingen van de Proof of Concept uit 2009, zoals ‘verkeer optimaal over het netwerk verdelen’. Die algemeen geformuleerde oplossingen zijn vertaald in drie regels:

  1. Reageer niet op files, maar anticipeer erop. Door een file vóór te zijn, voorkom je de capaciteitsval.
  2. Zorg ervoor dat verkeerstromen niet onnodig gehinderd worden. Voorkom daarom blokkades en terugslag bij kruispunten en aansluitingen. Hiervoor wordt de kracht van de regelingen aangepast aan de actuele situatie.
  3. Los een verkeersprobleem zoveel mogelijk op op het niveau waar het probleem zich voordoet (waar de ‘kiem’ ligt). Door gelaagd te regelen en tijdig op te schalen kun je het netwerk optimaal benutten.

Die regels zijn vervolgens op proefgebied van de A10 West geprojecteerd. Er is gekeken naar frequent voorkomende problemen in dit gebied en naar oplossingen in lijn met bovengenoemde regels.

DE FUNCTIONELE COMPONENTEN

Om deze nog papieren regels handen en voeten te geven, hebben de partijen in de Praktijkproef nieuwe softwarecomponenten ontwikkeld die intelligentie toevoegen aan de bestaande detectie- en regelsystemen op straat. Ook zijn enkele ‘off the shelf’-producten van private marktpartijen aangepast om ze in het regelconcept te kunnen passen. Het gaat om monitoringeenheden, bedoeld om dreigende knelpunten op te sporen en de regelruimte (bufferruimte) te bepalen, om regeleenheden, die de toeritdoseerinstallaties (TDI’s) en verkeersregelinstallaties (VRI’s) met de juiste kracht inzetten, om supervisors, de laag boven de regeleenheden.
Op het overzicht hieronder staan alle componenten die de Praktijkproef Amsterdam mogelijk maken, bij elkaar. Merk op dat de componenten via een gemeenschappelijke databus met elkaar zijn verbonden, de PPA-bus. De software van de verschillende leveranciers zijn zo gemaakt, dat ze met elkaar kunnen ‘praten’: de ontwikkelaars hebben afspraken gemaakt over het formaat waarin de gegevens naar de databus worden weggeschreven en kunnen worden uitgelezen. De centrale databus heeft als bijkomend voordeel dat alle componenten met één centrale gebruikersinterface en een integrale logging kunnen worden geanalyseerd. Ook is met deze opzet een (conceptuele) basis gelegd waar we mogelijk in de toekomst op voort kunnen bouwen.

____


1
De Fileschatter schat de toestand van de rijksweg – snelheid, intensiteit en dichtheid – en biedt daarmee inzicht in de krapte dan wel ruimte op het snelwegennet. De Fileschatter baseert zich op de (lus)data van de Meetraaimanager, die tijdens de proef voor het eerst succesvol is toegepast. Voordeel is dat de data uit de inductielussen iedere 25 sec. beschikbaar komen. Ook houdt de Meetraaimanager rekening met de beeldstanden van het snelwegsignaleringssysteem (afkruisen, gebruik vluchtstrook enzovoort).

2
De Kiemenspeurder lokaliseert tijdig mogelijke kiemen op het snelwegennet. Hiertoe vergelijkt de speurder de output van de Fileschatter met historische data. De Kiemenspeurder is ook in staat om de kop en de staart van de congestie te lokaliseren.

3
De Parameterschatter bepaalt op basis van de actuele verkeerssituatie adaptief de ideale set met regeldoelen voor de TDI’s en de ‘supervisors’ die het traject en het deelnetwerk regelen. Het schatten van de parameters is noodzakelijk, omdat regeldoelen als kritische dichtheid en capaciteit gedurende de dag aanzienlijk kunnen fluctueren.

4
De Wachtrijschatter schat de wachtrijen bij TDI’s en VRI’s. Om wachtrijen van 150 tot 300 meter goed te kunnen schatten, is vaak aanvullende detectie nodig of dienen lussen van stroomopwaarts gelegen kruispunten als input. Als er geen lussen in de omgeving beschikbaar zijn, wordt een gemeten historisch instroomprofiel gebruikt.

5
Op basis van de beleidsmatig beschikbare ruimte en de actuele wachtrijlengte – de input van de Wachtrijschatter – stelt de Bergingsindicator iedere minuut de beschikbare regelruimte voor de TDI’s en VRI’s vast.

6
Bij grote drukte in het netwerk, bijvoorbeeld ten gevolge van incidenten, is het toegestaan om de bufferruimte te vergroten. De monitoringeenheid Functioneringsniveau bepaalt de toegestane kracht van het regelen aan de hand van de prestatie van het netwerk (gemiddelde dichtheid en de ruimtelijke spreiding van het deelnetwerk).

7
Zodra er geregeld moet worden volgens het regelconcept van de Praktijkproef, ‘overrulet’ het TDI-algoritme de standaardinstellingen en algoritmes van de TDI’s op straat. Het TDI-algoritme op grond van de lokale situatie ter hoogte van de toerit met een ‘feedback-aanpak’: er wordt continu gemeten wat de effecten zijn van de regelingreep en daarop wordt de kracht van het regelen aangepast.
Het TDI-algoritme kan ook als ‘master’ een door de Kiemenspeurder geïdentificeerde kiem aanpakken of als ‘slave’ opdrachten uitvoeren van de Supervisor A10 West.

8
Zodra er een probleem dreigt te ontstaan op de A10 West, zullen de TDI en VRI op de eerste aansluiting stroomopwaarts het probleem proberen weg te regelen. De Supervisor A10 West bepaalt vervolgens of ook aansluitingen verder stroomopwaarts moeten ‘meeregelen’ door gaten in de verkeersstroom richting het potentiële knelpunt te creëren.

9
De Supervisor Aansluiting beheerst de toevoer vanuit het stedelijke netwerk naar de toeritten. Het zorgt ervoor dat deze toeritten niet te snel vollopen als de TDI’s aan staan en voorkomt blokkades op het stedelijke wegennet.

10
De Supervisor Deelnetwerk regelt de afstemming tussen de Supervisor A10 West en de Supervisor Aansluiting. Op basis van data die deze supervisor van de verschillende componenten ontvangt, bepaalt hij de ruimte en krapte in het netwerk, leidt hij regeldoelen af en geeft hij die door aan de betreffende supervisors.
 

Maximale flexibiliteit dankzij de PPA-bus

Tekst: Paul van Koningsbruggen, Technolution

In de Praktijkproef Amsterdam is onder een stevige tijdsdruk gewerkt. Algoritmen bijvoorbeeld werden vaak direct uit kennislaboratoria naar de straat gebracht. Ook werkten de deelnemende partijen vaak tegelijkertijd aan de verschillende componenten van het regelconcept, die uiteindelijk allemaal ‘in elkaar geklikt’ moesten worden. Dat dat überhaupt goed is gegaan, heeft alles te maken met de flexibiliteit die de PPA-bus bood.

Koppelvlak
De PPA-bus is een open, leveranciersonafhankelijk koppelvlak waarop de partijen hun componenten aansluiten, en waarmee ze data beschikbaar stellen en data lezen. De bus is gebaseerd op een open source Enterprise Service Bus (ESB) die speciaal voor de Praktijkproef ‘op maat’ is gemaakt.
Hoe is dat zijn werk gegaan? Allereerst is vastgesteld welke functionaliteit precies nodig is. Een ESB biedt een rijke set aan mogelijkheden, maar voor de Praktijkproef was vooral de databusfunctionaliteit van belang. Omdat de PPA-bus als verbindend element dé kritische component is in het Praktijkproef-systeem, is niet meer functionaliteit toegevoegd dan strikt noodzakelijk: zo blijft de bus ‘clean’ en goed beheersbaar. De PPA-bus is bovendien redundant uitgevoerd om bij uitval op de ene locatie direct door te kunnen schakelen naar de andere locatie.
De bij de Praktijkproef betrokken partijen hebben tegelijkertijd de interfaces van de losse systemen en applicaties met de PPA-bus gedefinieerd en vastgelegd. Zo kon ieder partij zijn eigen ontwikkeling realiseren en aansluiten op de PPA-bus. Als laatste is een mens-machine interfaceapplicatie gekoppeld aan de PPA-bus. Deze interface maakt het mogelijk mee te kijken met de prestaties van het systeem.

____


De componenten in actie
Hoe werken de verschillende componenten in de praktijk? We nemen dat aan de hand van een voorbeeld door.
Het Amsterdamse regelconcept is er onder meer op gericht problemen tijdig te signaleren, zodat een capaciteitsval kan worden voorkomen of in ieder geval uitgesteld. Om dit anticiperend regelen mogelijk te maken, monitort de Fileschatter constant het verkeer op de A10. De Kiemenspeurder interpreteert de output van de Fileschatter met behulp van historische data en is zo in staat potentiële kiemen te lokaliseren. Stel bijvoorbeeld dat de Kiemenspeurder signaleert dat er problemen in de Coentunnel ontstaan, dan zal de instroom vanuit de stroomopwaarts gelegen aansluiting S101 direct beperkt worden. De doseerintensiteit die de TDI op de S101 meekrijgt, wordt berekend door de Parameterschatter (deze component berekent de doseerintensiteit van alle TDI’s langs de A10 West). Het punt is alleen dat de TDI de berekende doseerintensiteit maar kort kan aanhouden, omdat de opstelruimte ter plaatse beperkt is. Een toerit op de A10 West kan maximaal zo’n 40 voertuigen bergen – bij meer slaat de wachtrij over het stroomopwaartse kruispunt heen. Met een aanbod van 1200 voertuigen per uur en een gewenste doseerintensiteit van 600 voertuigen per uur wordt de TDI op de S101 dus al snel ‘overvraagd’!
Zodra de TDI op de S101 aan is gezet, kijken daarom continu twee supervisors mee. De Supervisor A10 West laat wanneer nodig aansluitingen verder stroomopwaarts meeregelen: de S102, S104 enzovoort. De werking is gebaseerd op een eenvoudige die de beschikbare bufferruimte evenredig verdeelt. De Supervisor Aansluiting zorgt er daarbij voor dat de toeritten niet vollopen: het beheerst de aanvoer vanuit het stedelijke wegennet. Hoe ver het kan en mag gaan bij het bufferen van het stedelijke verkeer, wordt weer bijgehouden door de Wachtrijschatter en de Bergingsindicator. De eerste schat de actuele wachtrijlengte bij VRI’s en de laatste vergelijkt dat met wat beleidsmatig is toegestaan (= de bufferruimte). De lokale regeling of de netwerkregeling wikkelt het verkeer op de kruispunten verder zelf af.

Meer toepassingen
De verschillende componenten van de Praktijkproef grijpen dus ingenieus op elkaar in, zodanig dat ze als systeem het regelconcept tot leven brengen. Tegelijkertijd echter zijn de componenten zo opgezet, dat ze ook gemakkelijk buiten de proef, op andere plekken, zijn in te zetten. Je zou met de Fileschatter en Kiemenspeurder bijvoorbeeld heel goed reguliere regelscenario’s kunnen aansturen.
Hetzelfde geldt voor de Wachtrijschatter en de Bergingsindicator op het onderliggende wegennet: een gemeente of regio zou deze kunnen gebruiken bij regelscenario’s waar de ‘voor- en narang’ worden geregeld op basis van beleidsmatige randvoorwaarden.

TESTEN, TUNEN EN ANALYSEREN

Om dit complexe systeem vooraf goed te kunnen testen, hebben de partijen een testomgeving gecreëerd die vrijwel gelijk was aan het operationeel systeem op straat. Zo kon de softwarefunctionaliteit van de ontwikkelde componenten, de databus, de logging, de gebruikersinterface en de algoritmen volledig ‘in huis’ worden getest – stap 1 in de testfase. Het microscopische model Vissim speelde hierbij een belangrijke rol. Vissim leverde de status van de lussen op straat als input aan de monitoringeenheden, die weer de regeleenheden voeden, die op hun beurt weer stuursignalen naar de VRI’s en TDI’s zenden, als ware het de situatie in de praktijk.
Stap 2 in de voorbereiding was het testen van de technische werking op straat. Component voor component is met eenvoudige interfacetesten gekeken of ze het inderdaad deden. Stap 3 bestond uit een test op straat met de meest elementaire uitvoering van de regelaanpak, de afstemming tussen een TDI met één of meerdere VRI’s. Hiervoor is de meest verkeerskundig complexe aansluiting van de S101 gebruikt. Deze aansluiting is complex omdat er vanuit vijf richtingen continu verkeer richting de toerit rijdt. Ondanks de uitgebreide in-huistesten kwamen bij deze straattests nog een groot aantal technische en functionele problemen aan het licht. Hierdoor heeft er geen uitgebreide tuning kunnen plaatsvinden.

Analysetools
Stap 4 ten slotte was het testen van de (stapsgewijze) implementatie op straat. Daarbij is intensief gebruik gemaakt van verschillende analysetools en webcams op straat. Bij het operationeel testen en inregelen van het systeem bleek bijvoorbeeld de geografische userinterface, GUI, erg nuttig. Met deze GUI kon alle relevante data naar wens op een geografische ondergrond worden afgebeeld. Ook is het mogelijk meerdere schermen open te zetten, zodat tegelijkertijd het functioneren van het netwerk als geheel en het functioneren van één of meer aansluitingen kan worden bekeken. Nog een onmisbaar handigheidje is dat dankzij de ‘replay’-functie – alle data in de PPA-Bus wordt gelogd – ook achteraf nog eens teruggekeken kan worden wat er nu precies is gebeurd.
Behalve de GUI is ook gebruik gemaakt van de PPA Analysetool die specifiek voor de Praktijkproef is ontwikkeld. Deze tool biedt een gedetailleerd inzicht in de werking van de componenten over een langere periode van de dag. Op grond van de resultaten uit de simulatie- of praktijkomgeving voert de PPA Analysetool een groot aantal tests uit, waarvan de resultaten overzichtelijk met behulp van grafieken worden gepresenteerd.
De analysetool bleek bijzonder nuttig voor het snel opsporen van fouten in de implementatie van de componenten en de gekozen instellingen voor het regelen. Ter illustratie: de PPA Analysetool is ingezet bij het inregelen van de aansluiting bij de S101. Een aantal foutieve instellingen konden daarmee snel worden opgespoord.
Een ander praktisch hulpmiddel voor het testen op straat zijn webcams. Hiermee zijn vanuit de ontwerptafel de componenten op straat getest en kon direct worden ingegrepen als er iets fout ging. Deze camera’s zijn zeer waardevol gebleken voor het testen in de praktijk. In de eerste plaats kun je veel meer tegelijk zien en een relatie leggen tussen de data en de beelden. Vooral bij het tunen van de wachtrijschatter op toeritten en het stedelijk wegennet hebben de camera’s hun nut bewezen.

1. Een screenshot van de geografische userinterface die in de Praktijkproef wordt gebruikt.
De PPA Analysetool: Inschakelmomenten TDI en regelstatus.
De PPA Analysetool: Bufferruimte van de belangrijkste buffers bij de aansluiting S101.
De PPA Analysetool: In deze figuur zien we duidelijk dat zich afwisselend banden met een hoge dichtheid (lichtblauw) en een lage dichtheid (donkerblauw) vanaf de S102 naar de S101 verplaatsen. Dit zijn de gaten in de verkeersstroom die door de ‘slave’ S102 worden gecreëerd.



LEERERVARINGEN

Het belangrijkste doel van de Praktijkproef was en is om inzicht te bieden in de (kosten)effectiviteit van gecoördineerd netwerkbreed verkeersmanagement. Dat betekent dus dat er bij de uitvoering zaken fout kunnen en mogen gaan – ook daar leer je van. In verschillende stappen van de proef zijn dan ook relevante ‘goed/fout’-ervaringen opgedaan die voor het succesvol uitvoeren van gecoördineerd netwerkbreed verkeersmanagement essentieel zijn.



Leerpunt 1: Basis op orde
Bij de start van het project is vastgesteld dat voor een goede proef de volgende onderdelen op orde moeten zijn en moeten worden gehouden:

  • De VRI’s en TDI’s moeten zowel technisch als functioneel correct functioneren.
  • Van alle relevante dynamisch-verkeersmanagementsystemen moet het technisch en functioneel beheer worden geregeld. Zowel het beheer van de afzonderlijke onderdelen als het beheer van de keten waar de onderdelen deel van uitmaken.
  • De monitoringsystemen moeten geschikt zijn om de ‘krapte en ruimte’ in het netwerk te bepalen.
  • VRI’s en TDI’s moeten data kunnen uitwisselen met een verkeerscentrale.

Dit lijken evidente zaken, maar het op orde brengen van de basis heeft meer voeten in de aarde gehad dan bij aanvang was ingeschat.

Leerpunt 2: Onderbouwde keuze van het netwerk
Om de effecten van een gecoördineerde inzet van maatregelen te kunnen bepalen, is het belangrijk een netwerk te kiezen dat voldoende groot is om problemen aan te kunnen pakken. Ook dienen de wegen in dit ‘proefnetwerk’ voldoende relatie hebben met de knelpunten die zich veelvuldig in het netwerk voordoen. Naast een knelpuntanalyse is het dus van belang om een goede inschatting te maken van de effectiviteit van de beschikbare regelruimte (bufferruimte). Het gaat niet alleen over de beschikbaarheid van de bufferruimte, maar ook of deze een sterke relatie heeft met de aan te pakken knelpunten. Verkeer tegenhouden dat maar een beperkte bijdrage levert aan de oplossing van het probleem zal niet leiden tot een verbeterde netwerkprestatie, zeker niet als hierbij ook andere zware verkeerstromen worden gehinderd.
Het is daarom wenselijk om in de toekomst herkomst-bestemmingsinformatie uit voertuigen real-time beschikbaar te krijgen en de regelalgoritmen op basis van deze informatie te laten bepalen wanneer de inzet van een buffer nog effectief is. Buffers die gegeven de verkeerssituatie in het netwerk niet effectief meer zijn zullen dan eerder op non-actief worden gesteld. Hiermee worden onnodige verliezen voorkomen. Dit is een belangrijk punt om mee te nemen naar fase 2 van de Praktijkproef Amsterdam!

Leerpunt 3: Verdere verkeerskundige optimalisaties zijn nodig
Door de strakke planning was er slechts beperkt tijd beschikbaar voor het inregelen van de algoritmes. Het lukte dan ook niet altijd om optimale keuzes te maken voor de parameters van de regelaar en de configuratie.
Op basis van een eerste analyse van de door het systeem gelogde data zien we dat het doseeralgoritme en de Parameterschatter op zich hun werk hebben gedaan: de intensiteit die wordt gerealiseerd in de tunnel ligt 7 à 8% hoger dan de afrijcapaciteit (= de capaciteit, oftewel het aantal voertuigen dat per tijdseenheid passeert, als een eenmaal ontstane file oplost). Hiermee besparen we al een aanzienlijke hoeveelheid voertuigverliesuren op de A10 West. Maar omdat de capaciteitsval in de Coentunnel zo’n 13% bedraagt, is die 7 à 8% nog niet voldoende. De verwachting is dat we met een betere afstelling van het ontwikkelde doseeralgoritme een hogere intensiteit – zeg 10% hoger dan de afrijcapaciteit – moeten kunnen realiseren, waardoor we nog meer voertuigverliesuren besparen. Dit is een aandachtspunt voor de verdere ontwikkeling van het concept.
Behalve dat het doseeralgoritme verbeterd kan worden, verdienen ook de buffers zelf aandacht. In sommige gevallen zouden we door het aanpassen van de verkeerslichten en de belijning ‘exclusief’ kunnen bufferen. Dit betekent dat je dan alleen buffert in het opstelvak met een directe relatie met de toerit, zodat er geen onnodige vertragingen ontstaan op andere gecombineerde rijrichtingen.
Daarnaast kunnen we op grond van de meetdata een afweging maken tussen de winst die wordt behaald door het uitstellen van de capaciteitsval (de genoemde 7-8% winst in ‘effectieve’ capaciteit) en de extra hinder die verkeer ondervindt dat geen relatie heeft met het probleem op de A10 West, maar dat toch wordt gebufferd. Het blijkt dat de grenswaarde voor de fractie verkeer met een relatie met de kiem, op zo’n 50% ligt. Met andere woorden, alleen buffers waarvoor geldt dat meer dan 50% van het verkeer richting de kiem op de A10 West rijdt, kun je zinvol inzetten. Dit bleek in de huidige situatie zeker niet het geval: een aantal buffers op de S102, maar ook de buffers bij de aansluitingen S104 tot en met S107 bleken achteraf een veel minder sterke relatie te hebben met de kiemen op de A10 West (in de Coentunnel). Als we deze buffers niet zouden meenemen in de gecoördineerde aanpak, voorkomen we een aanzienlijk aantal voertuigverliesuren op het stedelijke wegennet, zonder dat de situatie op hoofdwegennet heel veel verslechtert.
De belangrijkste optimalisatie zit echter in het inschakelmoment van de TDI’s. Uit de metingen blijkt dat de TDI’s gemiddeld een half uur tot een uur te vroeg inschakelen, maar in sommige gevallen zelfs twee uur te vroeg. Dit betekent dat de Kiemenspeurder te snel aanslaat op een potentiële kiem die de TDI’s moeten wegregelen. Berekeningen laten zien dat een verbeterde, goed ingeregelde Kiemenspeurder meer dan 30% in voertuigverliesuren op het stedelijke wegennet kan besparen.
Tot slot is het de vraag of het geconditioneerd flushen – de doseerintensiteit gelijk maken aan de verkeersvraag naar de toerit als de toerit volstaat – zinvol is of juist averechts werkt. Het is op basis van de metingen niet duidelijk geworden of na een capaciteitsval op de rijksweg de verliezen op het stedelijke wegennet opwegen tegen de winst op het hoofdwegennet. Deze vraag kan op basis van de huidige meetgegevens niet worden beantwoord, maar is zeker de moeite waard om te onderzoeken.

Leerpunt 4: Concept ook op kleinere schaal toepasbaar
Het doel van de Praktijkproef is het grootschalig in de praktijk beproeven van een nieuw regelconcept dat ook op andere plaatsen in Nederland én daarbuiten kan worden uitgerold. Het idee is dan niet om dan exacte kopieën van de proef neer te zetten, want er zijn verder nergens zoveel toeritten achter elkaar die met een TDI worden geregeld als in Amsterdam. Het gaat bij een uitrol dus vooral om de aanpak als zodanig en om de daarvoor ontwikkelde componenten, die steeds weer in een andere samenstelling kunnen worden ingezet.
Bij de beschrijving over de monitoringeenheden gaven we al aan dat bijna alle monitoringeenheden geschikt zijn om in regelscenario’s te worden ingezet. De Supervisor Aansluiting kan de effectiviteit van bestaande TDI’s verhogen door de bufferruimte van de toerit uit te breiden met de opstelvakken van de stroomopwaartse VRI. Zelfs op plekken waar nu geen TDI staat vanwege ruimtegebrek of onvoldoende effectiviteit, zou deze nieuwe vorm van toeritdosering uitermate effectief kunnen zijn.
De Feedbackregelaar kan ingezet worden om bijvoorbeeld blokkades op stedelijke en provinciale wegen te voorkomen of wachtrijen daar neer te zetten waar ze het minste kwaad kunnen. Een voorbeeld van een dergelijke toepassing is in voorbereiding bij de Maastunnel in Rotterdam.



HOE VERDER? DE INTEGRATIE VAN WEGKANT- EN IN-CAR SPOOR

De eerste fase van de Praktijkproef Amsterdam heeft laten zien dat het concept van gecoördineerd netwerkbreed verkeersmanagement inderdaad kan worden vertaald in een generieke regelaanpak. Zoals uit de leerervaringen blijkt, kan het allemaal nog een stuk beter, maar juist daarvoor is de proef uitgevoerd. Nu zal er binnen het wegkantspoor van de Praktijkproef een goede verbeterslag gemaakt kunnen worden, maar interessant zijn ook de mogelijkheden die het in-car spoor biedt. Een mooi voorbeeld is de Wachtrijschatter. Betrouwbare schattingen maken van de lengtes van de wachtrijen zijn essentieel voor de regelaanpak, maar met de huidige detectiemogelijkheden blijkt dat geen sinecure. Hier zou de integratie van wegkant en in-car soelaas kunnen bieden. Zoals al in een eerdere uitgave van NM Magazine werd geschetst, biedt het fuseren van gegevens uit de inductielussen met floating car data ongekende mogelijkheden om de betrouwbaarheid van de wachtrijschattingen te verhogen. De mogelijkheden van datafusie gaan zelfs verder: het gebruik van in-car data maakt het in de toekomst wellicht mogelijk om de hoeveelheid lussen op de snelweg aanzienlijk te verlagen, terwijl de kwaliteit van de data en de geschiktheid van de data voor verkeersmanagementdoeleinden gelijk blijft of beter wordt. Bovendien krijgen we inzicht in de routes die automobilisten kiezen en daarmee ook in de fracties verkeer die van een bepaalde buffer naar de kiem rijden. Met dergelijke informatie kunnen we real-time bepalen of we een bepaalde buffer wel zinvol kunnen inzetten!
Maar de integratie wegkant en in-car levert meer voordelen op dan alleen datafusie. Zo kan wegkant actief in-car ondersteunen en vice versa. Stel dat er sprake is van een incident waardoor een groot deel van het verkeer over een alternatieve route moet worden geleid. In dit geval kunnen de wegkantsystemen ervoor zorgen dat de alternatieve route de grotere verkeersvraag aankan, bijvoorbeeld door de aanwezige verkeersregelingen (maximale verlenggroentijden) aan te passen. Ook het gebruik van in-car technologie voor het uitvoeren van verkeersmanagementtaken ligt voor de hand. Denk aan hoofdrijbaandosering door het gebruik van in-car dynamische snelheden.
De vervolgfase van de Praktijkproef Amsterdam kan dus een belangrijke rol innemen in de transitieopgave ‘van wegkant naar integratie wegkant en in-car’ voor modern verkeersmanagement. Anders dan bijvoorbeeld het A58 Spookfile-project richt de Praktijkproef Amsterdam zich op het grootschalig in de praktijk beproeven van gecoördineerd netwerkbreed verkeersmanagement (wegkant én in-car) in stedelijk gebied. Daarbij gaat het niet alleen om de ontwikkeling van techniek, maar beoogt de Praktijkproef ook bij te dragen aan een overkoepelende functionele architectuur voor verkeersmanagement in de toekomst.
Ten slotte is het belangrijk op te merken dat de Praktijkproef Amsterdam als project niet op zichtzelf staat, maar deel uitmaakt van het publiek-private Connecting Mobility-programma. Mede om die reden richt Praktijkproef zich op de transitiepaden zoals die in het kader van Beter Geïnformeerd op Weg en Connecting Mobility zijn geformuleerd. De belangrijkste bijdragen van PPA richten zich hierbij op de transitiepaden 1, 2 en 6: ‘Van collectieve beïnvloeding naar een slimme mix van collectieve en individuele dienstverlening’, ‘Een veranderende rol van wegkantsystemen’ en ‘Van overheidsregie naar publiek-private samenwerking en allianties’. Aangezien alle grote steden in de wereld kampen met vergelijkbare problemen, biedt dat niet alleen interessante uitrolmogelijkheden in Nederland, maar ook kansen in het buitenland!

____

De auteurs
Jaap van Kooten is directeur van Arane Adviseurs.
Prof. dr. ir. Serge Hoogendoorn is hoogleraar Verkeersstromen aan de TU Delft.