Door hun samenwerking slim in te richten kunnen wegbeheerders en serviceproviders prima sámen aan een vlotte afwikkeling van het verkeer werken – zoveel heeft het programma SOCRATES2.0 wel bewezen. Voor een wat grootschaliger samenwerking is de functie Netwerkmanager dan wel cruciaal. Welke rol speelt deze component? En hoe gaat dat (boven)regionaal managen precies in z’n werk?
Het artikel ‘SOCRATES2.0: Nieuwe mogelijkheden voor interactief verkeersmanagement’ beschrijft een aantal samenwerkingsmodellen voor wegbeheerders en serviceproviders. In het complexere model Gecoördineerde aanpak, waarin de publieke en private partijen écht gaan samenwerken, speelt de Netwerkmanager een centrale rol. Dit is een rolhouder (een wegbeheerder en/of een ‘trusted partner’), maar het is ook een applicatie die automatisch serviceverzoeken voor de wegbeheerders (verkeerscentrales) en serviceproviders genereert.
De Netwerkmanager als applicatie is bedoeld voor multimodaal verkeer en kan doelen nastreven op het gebied van doorstroming, leefbaarheid en veiligheid. In dit artikel bespreken we hoe dat precies werkt. We nemen een metropolitaans netwerk als voorbeeld en – om de uitleg een beetje behapbaar te houden – richten ons specifiek op het doel doorstroming en de modaliteit gemotoriseerd verkeer. Anders gezegd: we streven voor ons (boven)regionale netwerk naar een vlotte en veilige doorstroming met gepaste dichtheden van verkeer over het hele beschouwde netwerk heen, met een minimale verliestijd.
De Netwerkmanager van ons voorbeeld heeft de opbouw zoals weergegeven in figuur 1. De drie belangrijkste componenten zijn 1) de Netwerkindicator, 2) services en 3) de Netwerksupervisor. We lopen deze een voor een langs.
Netwerkindicator
Aan de basis van de regelaanpak staat de Netwerkindicator. Uitgaande van floating car data en lusdata kent de Netwerkindicator aan elke schakel in het wegennetwerk een score voor de verkeersafwikkeling toe. Het gaat dan steeds om twee scores per schakel, één voor de actuele toestand en één voor de toekomstige toestand (een voorspelling van 15 minuten vooruit). De scores noemen we ook wel servicelevels en lopen van A tot en met F.
Figuur 2 toont een voorbeeld van een scoreverdeling gebaseerd op het aantal voertuigverliesuren en de productie. Wanneer de productie hoog is en het aantal voertuigverliesuren laag, is er sprake van optimale doorstroming, oftewel servicelevel A. Bij toenemende drukte neemt het aantal verliesuren toe, maar dit gaat nog niet echt ten koste van de productie. Bij nog meer drukte zakt de prestatie in. Op een autosnelwegschakel treedt de bekende capaciteitsval op, terwijl er bij kruispunten blokkades ontstaan, inclusief terugslag stroomopwaarts over de schakels in het netwerk. De Netwerkindicator kent dan de slechtste score toe, servicelevel F. Uitgedrukt in vertraging per kilometer staat het servicelevel A in figuur 2 voor minder dan 30 seconden. Dit loopt op in stapjes van 30 seconden tot een vertraging van meer dan 2,5 minuut bij servicelevel F.
De scoreverdeling verschilt overigens per type weg. Autosnelwegen hebben bijvoorbeeld een hogere maximale productie dan stedelijke wegen. De mate waarin de productie van een stedelijke schakel inzakt bij beginnende congestie, hangt weer sterk af van de kans op blokkades en terugslag door bijvoorbeeld verkeerslichten. Maar omdat er wordt gekeken naar de relatie, zijn de servicelevels van verschillende typen wegen toch goed te vergelijken.
De Netwerkindicator geeft dus als uitvoer een servicelevel per schakel. Maar deze wordt ook geaggregeerd tot een servicelevel per corridor. Uiteindelijk kan de prestatie van het beschouwde netwerk met één score worden uitgedrukt.
Services
Dan de tweede component van de Netwerkmanager, de services. Dat is onze gereedschapskist, gevuld met maatregelen en informatiediensten die wegbeheerders met hun wegkantinstrumenten en serviceproviders met hun navigatiediensten kunnen inzetten. Die services hebben binnen de Netwerkmanager de vorm van verkeerskundige verzoeken, zoals ‘instroom beperken’, ‘uitstroom verhogen’ en ‘spreiden van verkeer’. Merk op dat een service niet voorschrijft hoe een en ander precies gerealiseerd moet worden: de wegbeheerders en serviceproviders zijn zelf verantwoordelijk voor het nader invullen van een verzoek als ‘instroom beperken’.
Hoe wordt zo’n service precies aangevraagd? Schakels in het netwerk gebruiken de Netwerkindicator om te bepalen in hoeverre zij een service (nog) nodig hebben, gelet op het actuele servicelevel. Voor een schakel is dan bijvoorbeeld vastgelegd dat ingrijpen met service X gewenst is zodra het serviceniveau naar C zakt, en dat vanaf servicelevel D ook service Y moet worden ingezet. Geeft de Netwerkindicator aan dat het serviceniveau inderdaad zakt naar C of D, dan is dat de trigger om de betreffende service(s) aan te vragen.
Bij dit aanvragen houden we nog geen rekening met de effecten van de service op andere schakels in het netwerk. Omgekeerd houden we ook geen rekening met effecten als gevolg van services die door andere schakels zijn aangeroepen. Dat is namelijk de taak van de derde component.
Netwerksupervisor
De zogeheten Netwerksupervisor, component 3 in figuur 1, is er verantwoordelijk voor de aangeroepen services in een netwerk op elkaar af te stemmen. Alle informatie komt hier samen: de servicelevels van de schakels in het netwerk, op welke schakels met welke services (lokaal) ingegrepen wordt en wat de reikwijdte van elke actieve service is. De Netwerksupervisor gaat vervolgens na of er mogelijk conflicten tussen services ontstaan. Daarvoor put de applicatie uit een interactiematrix. Aan de hand van die matrix is duidelijk welke services qua ‘regelgebied’ overlappen en waar dus een zekere interactie is. Rekening houdend met deze interacties én met de prioriteringsregels – regels die bepalen bij welke condities welke services vóór gaan, uitgaande van de beleidsuitgangspunten – bepaalt de Netwerksupervisor uiteindelijk welke samenhangende set aan services daadwerkelijk actief mogen worden. Die services zet de Netwerkmanager vervolgens uit bij de aangesloten wegbeheerders en serviceproviders. Zie ook bijgaand kader voor een voorbeeld van een (geautomatiseerde) ingreep.
Voorbeeld: De Netwerksupervisor aan het werk
Het verkeer tussen herkomst A en herkomst B kan normaliter van twee min of meer gelijkwaardige routes gebruikmaken: route Noord en route Zuid. Op zeker moment vindt op route Noord een incident plaats. Omdat het servicelevel daar snel inzakt, schakelt de Netwerkmanager – of meer specifiek: de Netwerksupervisor – service X in, ‘Verkeer herrouteren over route Zuid’.De Netwerkindicator voorziet echter dat door het extra verkeersaanbod het servicelevel van route Zuid zal verslechteren: het voorspelde servicelevel gaat achteruit. Dat triggert het aanvragen van service Y, ‘Uitstroom uit route Zuid verhogen’. Met deze service kan het extra verkeer beter worden verwerkt. De Netwerksupervisor merkt de interactie op en stelt vast dat deze interactie positief (versterkend) is – en dus wordt ook service Y ingeschakeld.
Een service om de uitstroom te verhogen kan echter ook conflicteren. Stel dat een andere schakel service Z aanvraagt. Deze service verhoogt de uitstroom op een van de aanvoerende links naar route Noord. Dat betekent dat service Z juist meer verkeer naar het incident wil sturen. Dit conflicteert met het regeldoel van service X. Vanwege het incident op route Noord zal in dit geval de Netwerksupervisor de aanvraag weigeren.
Eerste ervaringen
Tot zover de (papieren) beschrijving van de Netwerkmanager. Maar hoe werkt die in de praktijk? De beschreven case hebben we binnen SOCRATES2.0 prima kunnen beproeven in de Metropool Regio Amsterdam, MRA, vanaf september 2019. Deze proef loopt, enigszins vertraagd door corona, nog tot eind 2021. In deze pilot hebben de wegbeheerders gemeente Amsterdam, provincie Noord-Holland en Rijkswaterstaat, en de serviceproviders Be-Mobile, Brandmkrs en TomTom services beschikbaar gesteld en daarmee de ‘gereedschapskist’ van de Netwerkmanager gevuld.
Begin 2022 volgt een uitgebreide verkeerskundige evaluatie naar de effectiviteit van de Netwerkmanager in MRA. De eerste ervaringen zijn al positief. Technisch werkt alles goed en de serviceverzoeken van de Netwerkmanager worden in veel gevallen gehonoreerd. Per dag ontvangen de verkeerscentrales enkele tientallen automatische verzoeken, waarvan de wegverkeersleiders in de centrales 89 procent uitvoeren. De serviceproviders ontvangen zo’n 500 tot 800 verzoeken per dag, waarvan ook een fors deel – ongeveer de helft – gebruikt wordt om bijvoorbeeld routeadviezen aan te passen. De serviceproviders zien er daarbij op toe dat individuele gebruikers niet te lijden hebben van de verzoeken, zodat het vertrouwen in de diensten van de providers onverminderd hoog blijft.
Om de keuzes die de Netwerkmanager tijdens de proeven maakt, goed te kunnen analyseren, hebben we alle services op een kaart van het MRA-gebied ingetekend en de relaties tussen services schematisch weergegeven. Door zo te herleiden waarom welke services werden ingezet, hebben we de regelaanpak al verder kunnen aanscherpen. Zo hebben we bijvoorbeeld de (beleidsmatige) prioritering binnen de Netwerksupervisor aangepast. Ook hebben we interactiematrix opgeschoond: lang niet alle theoretische interacties tussen services zijn in de praktijk relevant. De complexiteit van het systeem hebben we zo fors kunnen verkleinen.
Uit de proeven blijkt trouwens overduidelijk hoe belangrijk het is om de basis op orde te hebben, oftewel ‘data op orde’ (van belang voor de Netwerkindicator) en ‘services op orde’ (component 2). Zonder deze basis kan de Netwerkmanager onlogische keuzes maken. Daarmee is het belang van een goede en betrouwbare samenwerking tussen wegbeheerders en serviceproviders nogmaals onderstreept!
Lat hoger leggen
Met dit inzicht in de functie van de Netwerkmanager is het tijd de samenwerkingslat hoger te leggen. In volgende toepassingen moeten we ook ander verkeer dan het gemotoriseerde verkeer meenemen – de applicatie is immers multimodaal. En het is belangrijk, zeker in de Nederlandse context, de samenwerking te zoeken met vaarweg- en spoorwegbeheerders. Wat betekent dat voor het doorontwikkelen van de Netwerkmanager?
De verkeerskundige literatuur laat zien dat de aard van de interacties sterk afhankelijk is van de functie van de weg. Dit betekent dat we de juiste vorm van verkeersmanagement en in het verlengde daarvan C-ITS moeten inzetten, passend bij de functie van de weg. Verder moeten we speciale aandacht besteden aan de uitwisselingen tussen wegen met verschillende functies.
Met het oog op de doelen leefbaarheid en veiligheid is het verder noodzakelijk om de servicelevels (en de kwaliteit) ruimer te definiëren. Naast voertuigverliesuren en productie moeten ook kwaliteitswaarden voor verkeersveiligheid en de kwaliteit van de leefomgeving een plek krijgen. Waarden die we moeten (leren) differentiëren naar modaliteit. De gedefinieerde regelaanpak staat dit zonder meer toe door de set aan meetdata te vergroten en de Netwerkmonitor verder te verrijken.
Dan de interactie met vaar- en spoorwegen. Deze interactie komt in eerste instantie met verstoringen in het wegennetwerk doordat bruggen worden geheven en spoorwegovergangen gesloten. Dit kan relatief eenvoudig worden toegevoegd aan de boven beschreven servicelevels. Een stap verder kunnen de actuele servicelevels bij interacties met vaarwegen worden meegewogen in de beslissing over wat het juiste moment is om de brug te heffen ten faveure van de scheepvaart. Dit vergroot de verantwoordelijkheid van de Netwerkmanager.
Nog een stap verder kan de regelaanpak worden opgeschaald naar meerdere modaliteiten door voor hen ook services toe te voegen aan de gereedschapskist. Dat is met de eenvoud van de scores A tot en met F eigenlijk overal toepasbaar.
De Netwerkmanager is voor deze aanpassingen en uitbreidingen open genoeg. Ook zijn er nog mogelijkheden voor verdergaande automatisering. De vervolguitwerkingen vragen natuurlijk om meer en andersoortige data, meer kennis en een bredere samenwerking. Maar het voorziene resultaat is navenant!
____
De auteurs
Drs. Edwin Mein is domeinarchitect bij Technolution.
Dr. Erik-Sander Smits is partner bij Arane Adviseurs.
Drs. Jan Maarten van den Berg is businessmanager van SOCRATES2.0 en (inmiddels) werkzaam bij NDW.
Ing. Hanneke Welten is teamleider Smart Mobility bij DTV Consultants.
