De technische en de operationele haalbaarheid van PPA-producten
De technische en de operationele haalbaarheid van PPA-producten
Amsterdam Bereikbaar & Praktijkproef Amsterdam
27 juni 2017
Versie: 1.0
Amsterdam Bereikbaar & Praktijkproef Amsterdam |
Onderwerp: De technische en de operationele haalbaarheid van PPA-producten |
Opdrachtgever: Praktijkproef Amsterdam |
Versie: 1.0 |
Projectnummer: INF 1704400 |
Colofon
AMSTERDAM BEREIKBAAR & PRAKTIJKPROEF AMSTERDAM |
Onderwerp De technische en de operationele haalbaarheid van PPA-producten |
OPDRACHTGEVER |
Praktijkproef Amsterdam Contactpersoon Xxxxx xxx Xxxxxxxxxx |
UITGAVE |
Revisie 1.0 - Definitief Datum 27 juni 2017 Auteur(s) Xxxxxxx xx Xxxx, Xxxxxxx Xxxxxx, Xxxxxxx Xxxxxxxx Goedgekeurd door Xxxxxxx Xxxxxxxxxx Projectnummer INF 1704400 Projectnaam Haalbaarheidsstudie PPA |
ADVIN |
Advin Xxxxxxx 000 0000 XX Xxxxxxxxx T (000) 000 00 00 |
2.2 Match tussen knelpuntenanalyse met kansen voor XXX-xxxxxxxxxxx | |||
BIJLAGE 1: BESPREKINGSVERSLAG RIJKSWATERSTAAT 18
BIJLAGE 2: BESPREKINGSVERSLAG AMSTERDAM 28
BIJLAGE 3: BESPREKINGSVERSLAG PROVINCIE NOORD-HOLLAND 37
De PPA-Stuurgroep heeft op 8 december 2016 besloten om een haalbaarheidsonderzoek uit te laten voeren naar de consolidatie- en de uitvoeringsmogelijkheden van eerder beproefde PPA-onderdelen. De regio voorziet grote problemen voor de bereikbaarheid van de Metropoolregio Amsterdam en heeft hiervoor et initiatief ‘Amsterdam Bereikbaar’ gestart. Het haalbaarheidsonderzoek PPA moet inzicht geven welke onderdelen inzetbaar zijn, welke randvoorwaarden ingevuld moeten worden en welk effect verwacht mag worden van deze maatregelen. Zo levert de haalbaarheidsstudie belangrijke bouwstenen voor de regionale partijen. Aan het projectteam is gevraagd om ook de beproefde Xxxx Xxxxxx maatregelen mee te nemen in het onderzoek. Het betreft de ervaringen die zijn opgedaan bij grote werkzaamheden rondom de projecten Schiphol-Amsterdam- Almere (SAA) en Renovatie Velsertunnel.
Het projectteam voor de haalbaarheidsstudie bestaat uit de volgende personen:
• Xxxxx xxx Xxxxxxxxxx – Projectleider
• Xxxxxx Xxxxxxxx – Provincie Noord-Holland
• Xxxx Xxxxxxxxx – Vervoerregio Amsterdam
• Xxxx Xxxxxx – Rijkswaterstaat, Praktijkproef Amsterdam
• Xxxxx xxx Xxxxxxxxxx – Rijkswaterstaat West-Nederland Noord
• Xxxx Xxxxxx – Rijkswaterstaat Verkeer en Watermanagement
• Xxxxx Xxxxxxxxx – Gemeente Amsterdam
• Xxxx Xxxxxxxxxxx– Xxxxxxxx Xxxxx; eindrapportage
• Xxxxxxx xx Xxxx – Advin; technische en operationele haalbaarheid
De haalbaarheidsstudie is opgebouwd uit vier deelrapporten:
1. Haalbaarheidsonderzoek toepassing Praktijkproef Amsterdam (Xxxx Xxxxxxxxxxx, Twynstra Xxxxx); In dit rapport komen de verschillende deelprojecten samen en wordt het integrale advies over de haalbaarheid van PPA-maatregelen en het Slim Reizen gegeven.
2. PPA Haalbaarheidsstudie, de knelpuntenanalyse (Xxxx xxx Xxxxxx, Arane);
In dit rapport worden de regionale knelpunten geïdentificeerd en wordt geanalyseerd welke type knelpunt dit is en welk PPA-onderdeel geschikt kan zijn.
3. Slim reizen onderdelen Haalbaarheidsstudie PPA (Xxxxxxxx xxx Xxxxxx, XTNT);
In dit rapport wordt de haalbaarheid getoetst van de verschillende Slim Reizen-maatregelen.
4. De technische en operationele haalbaarheid van PPA-onderdelen (Xxxxxxx xx Xxxx, Xxxxx);
Het voorliggende rapport gaat in op de verschillende PPA-onderdelen zoals deze zijn beproefd in deze regio én maatregelen die beproefd zijn in andere regio’s. Het geeft inzicht in de technische en operationele randvoorwaarden en geeft op basis daarvan een inschatting van de kansrijkheid. Dit rapport vormt de verbinding tussen de gesignaleerde knelpunten (Arane) en het haalbaarheidsonderzoek (Twynstra Xxxxx). Waar mogelijk wordt de link gelegd met het parallel uitgevoerde onderzoek naar Slim reizen (XTNT).
Voor het bepalen van de technische en operationele haalbaarheid zijn twee acties uitgevoerd. Bij de betrokken wegbeheerders is in interviews opgehaald wat de ervaringen zijn met de PPA-onderdelen. De match tussen de knelpuntenanalyse en welke kansen dit biedt voor PPA-maatregelen is gelegd in een workshop met het projectteam.
2.1 Interviews wegbeheerders
Bij de drie betrokken wegbeheerders zijn interviews afgenomen. Per interview is gezocht naar medewerkers die iets kunnen zeggen over het gebruik van de maatregel en iemand die gaat over het beheer (assetmanagement) van de maatregel. Bij de selectie van de geïnterviewden is gekozen om alleen eigen medewerkers van de betrokken wegbeheerders te bevragen.
Het interview met Rijkswaterstaat is gehouden op 10 mei van 11.00 tot 12.30 uur in de verkeerscentrale te Velsen. De deelnemers aan het interview waren:
• Xxxx xx Xxxxx (operationeel verkeerskundige VCNWN)
• Xxxx Xxxxxxx (namens de beheerder RWS West-Nederland Noord)
• Xxxxxxx Xxxxxx (verslag, Advin)
• Xxxxxxx xx Xxxx (projectleiding, Advin)
Het besprekingsverslag is toegevoegd in Bijlage 1.
Het interview met Gemeente Amsterdam is gehouden op 23 mei van 9.30 tot 11.00 uur op de Weesperstraat 8 te Amsterdam. De deelnemers aan het interview waren:
• Xxxxx Xxxxx (senior adviseur Assetmanagement, Gemeente Amsterdam)
• Xxx Xxxxxxx (ontwerper Openbare Werken en Verkeersontwerp, Gemeente Amsterdam)
• Xxxxxxx Xxx (gebruik, team verkeerstactiek, Gemeente Amsterdam)
• Xxxxxxx Xxxxxxxx (verslag, Advin)
• Xxxxxxx xx Xxxx (projectleiding, Advin)
Het besprekingsverslag is toegevoegd in Bijlage 2.
Het interview met de Provincie Noord -Holland is gehouden op 29 mei van 11.00 tot 12.30 uur op het Houtplein te Haarlem. De deelnemers aan het interview waren:
• Xxxxxxx Xxxxxx (verkeersregeltechnicus, Provincie Noord-Holland)
• Xxx Xxxxxx Xxxxx (xxxxxxxxxxxx, xxxxxxxxxx XX XXX, Xxxxxxxxx Xxxxx-Xxxxxxx)
• Xxxxxxx Xxxxxxxx (verslag, Advin)
• Xxxxxxx xx Xxxx (projectleiding, Advin)
Het besprekingsverslag is toegevoegd in bijlage 3.
De interviews zijn gehouden volgens eenzelfde opzet:
⮚ Kennismaking
⮚ Visie op verkeersmanagement (en de rol van PPA)
⮚ toetsen van de PPA-producten
⮚ toetsen overige onderdelen:
o niet PPA, wel GNV
o Slim reizen
⮚ overige bevindingen
In de interviews is ingegaan op de verschillende deelprojecten van PPA en de producten die zijn ontwikkeld:
1. PPA fase 1, Gecoördineerd Netwerkbreed Verkeersmanagement (GNV) op de A10 west
2. In-Car PPA
3. PPA fase 2 West, doorontwikkeling GNV
4. PPA fase 2 Zuid-Oost, privaat verkeersmanagement
5. PPA fase 2 Noord, GNV bij andere wegbeheerders
In de interviews zijn vragen gesteld om de technische en operationele haalbaarheid van de PPA-onderdelen te toetsen. Ook is ingegaan op het effect dat verwacht wordt door de inzet van de maatregelen en of er alternatieven zijn die mogelijk hetzelfde effect kunnen genereren. De bevindingen uit de gehouden interviews staan beschreven in hoofdstuk 3.
2.2 Match tussen knelpuntenanalyse met kansen voor PPA-producten
Het projectteam “Haalbaarheidsonderzoek toepassing Praktijkproef Amsterdam en Slim reizen” heeft op 23 mei in een workshop in Amsterdam de match gemaakt tussen de gesignaleerde knelpunten en de mogelijkheid om producten vanuit de PPA of vanuit Slim Reizen in te zetten. De bevindingen uit deze workshop staan beschreven in hoofdstuk 4.
3.1 Interviews wegbeheerders
Algemene beeld:
Alle wegbeheerders geven aan enthousiast te zijn over de PPA. De PPA heeft het mogelijk gemaakt om bepaalde ideeën en producten in de praktijk uit te proberen en dit heeft veel betekend voor de ontwikkeling van het verkeersmanagement. Men heeft geleerd wat nodig is om zaken werkend op straat te krijgen, welke barrières er zijn, welke partijen betrokken moeten worden en welke kosten dit met zich meebrengt. Die kennis helpt bij het maken van keuzes in de toekomst. Het inzetten van maatregelen (al dan niet PPA) is maatwerk, dus maatregelen zijn vrijwel nooit een-op-een inzetbaar. De kennis vanuit de PPA geeft wel inzicht hoeveel energie dit kost en welk effect verwacht mag worden.
3.1.1 Visies wegbeheerders
⮚ Rijkswaterstaat geeft aan dat ze werkt vanuit de Landelijke Regelaanpak (LRA) waarmee op regionaal niveau verkeersmanagement wordt uitgevoerd op basis van landelijke consistente regels. PPA GNV regelt op strengniveau (deelnetwerk). Dit kan effectief zijn, mits het past op het regelen van het gehele netwerk. PPA bevat instrumenten die kunnen worden toegepast in de LRA.
Rijkswaterstaat werkt vanuit een bepaalde architectuur. Hierin staan de Netwerkmanagementsystemen (NMS) van de drie overheden centraal. Aansturing van de onderliggende systemen (TDI’s, VRI’s, DRIPS) vindt plaats via het NMS. De uitwisseling tussen de overheden verloopt via de NMS’en.
⮚ Gemeente Amsterdam geeft aan dat de technologische ontwikkelingen snel gaan. Amsterdam heeft het maximale gehaald uit de klassieke verkeersmanagementtechnieken. Via sensoren en data neemt de informatie snel toe. Bovendien groeien enkele marktpartijen (bijv. Google) snel en verschuift de rolverdeling tussen markt en overheid. Amsterdam kiest ervoor om relatief veel van die ontwikkeling in eigen huis te laten plaatsvinden (in tegenstelling tot de Provincie Noord-Holland die meer op de markt zet). Daarnaast zet de gemeente in op de ontwikkeling van het zelfrijdend vervoer. PPA helpt stappen zetten bij deze veranderingen.
⮚ Provincie Noord-Holland geeft aan dat de provincie een koplopers rol vervult binnen Smart Mobility. Juist in de week van het interview heeft het Bestuur weer extra middelen vrijgemaakt voor deze ontwikkeling. Veel aandacht zal gaan naar Smart Mobility Schiphol. De Provincie ziet haar rol in het verkeersmanagement verschuiven. Via het programma iCentrale wordt verkend welke diensten door de markt vervuld kunnen worden. In de PPA heeft de Provincie gezocht naar een praktijkcasus die uitrolbaar is: een vraagstuk die op meer plekken in de regio (en daarbuiten) toepasbaar is, zodat de ontwikkelkosten laag kunnen blijven. Uitgangspunt voor de PPA-Noord was het inpassen van de PPA- producten in de reguliere architectuur.
3.1.2 Toetsen aan de PPA-producten
A. Basis op Orde
De basis op orde kent drie niveaus:
a) Basis is niet op Orde
b) Basis voldoet aan gestelde functionele en technische eisen
c) Basis is op orde voor PPA
Een belangrijke leerervaring vanuit de PPA betreft de constatering dat een fors deel van het areaal dan wel technisch, dan wel functioneel, niet deed wat het moest doen. PPA heeft ervoor gezorgd dat er meer aandacht is geschonken aan die basis.
Het eigen beheer bij RWS en PNH is redelijk op orde. Met name voor Amsterdam geldt, dat het assetmanagement nog op een ander (lager) niveau ligt. Denk hierbij aan de koppeling van de lussen aan de VRI’s.
Technische randvoorwaarde:
Amsterdam en PNH geven beiden aan dat het benodigde niveau voor PPA hoog ligt. Rond verkeerslichten is detectie gewenst en de regelautomaten moeten een bepaald niveau van intelligentie bevatten. Dit is een technische randvoorwaarde voor de uitrol. Niet alle spullen zijn direct geschikt voor GNV. Bij elk nieuw knelpunt moet getoetst worden of de spullen geschikt zijn en zo nee, wat nodig is om ze geschikt te maken. Zo geeft PNH het voorbeeld dat voor een VRI een investering van circa € 10.000 euro nodig is.
Operationele randvoorwaarde:
Het regionale ketenbeheer functioneert nog niet naar wens. De inzet vanuit Amsterdam en PNH is niet goed geborgd in de staande lijn. Beeld bij alle partijen is, dat door een betere organisatie van het ketenbeheer, de basis beter op orde kan komen en dat een betere basis voor regionaal verkeersmanagement wordt gelegd.
B. Meetraaimanager
Deze PPA-tool versnelt de levering van verkeersdata van de huidig 5 tot 7 minuten tot circa 1 minuut. Alle partijen geven aan dat men de functionele wens heeft om de data sneller beschikbaar te krijgen. De meetraaimanager heeft goed gewerkt voor de PPA op het hoofdwegennet.
Amsterdam en PNH geven aan dat de meetraaimanager primair levert voor het HWN en daarmee niet interessant is voor de eigen data. Wel hebben beide partijen de wens om snel informatie te krijgen van het HWN, daar kan de meetraaimanager een rol in spelen.
Amsterdam geeft nog aan dat een prestatie van circa 1 minuut vertraging prima is voor GNV, voor C-ITS toepassingen ligt de gewenste prestatie nog hoger, daarvoor zijn andere systemen nodig zoals glasvezel of G5.
Technische randvoorwaarde: RWS stelt de eis dat de levering moet passen binnen de bedachte architectuur. Levering van data moet lopen via het NDW. Aan deze technische randvoorwaarde is voldaan.
C. Kiemenspeurder
De kiemenspeurder is een PPA-tool die direct toepasbaar is, met name voor het HWN. Het instrument kan goed helpen bij de analyse van knelpunten.
Technische randvoorwaarde: voor het goed werken van het instrument moet de basis op orde (level PPA) zijn.
Operationele randvoorwaarde: het regelen met de kiemenspeurder is bewerkelijk en relatief duur. Zeker wanneer het netwerk groter wordt, dan wordt het werken met (verschillende) kiemen complexer.
D. Toepassing wachtrijschatter met lussen
Alle partijen geven aan dat het schatten van wachtrijen met lussen niet goed functioneert. Hiermee is de maatregel niet toepasbaar voor vervolgvraagstukken.
E. Toepassing wachtrijschatter met radardetectie
De partijen geven aan dat het schatten van wachtrijen met radardetectie goed mogelijk is. De maatregel wordt gezien als een volwassen maatregel en direct inzetbaar. Bovendien liggen er kansen, met radardetectie kunnen meerdere functies vervuld worden. Mogelijk leidt dit tot minder aanleg van lussen. Met name PNH geeft aan, dat wanneer er meer ingezet wordt op radardetectie, dat de meerkosten dan relatief mee kunnen vallen. PNH heeft behoefte aan een pilot zodat deze business case gemaakt kan worden.
Organisatorische randvoorwaarde: de radardetectie is nog niet in het reguliere beheer van het areaal opgenomen.
F. Toepassing wachtrijschatter met Floating-Car-Data (FCD).
Bij de wegbeheerders bestaat het beeld dat de resultaten van deze toepassing matig waren. Het schatten van de wachtrijen is (te) grof. Wel geeft Amsterdam aan dat via Be-Mobile een nieuwe proef loopt waarbij de verwachting is dat het schatten beter zal gaan. Ook verwacht Amsterdam dat de introductie van 5G een sprong de goede kant op is voor het schatten van wachtrijen. 5G is beter in staat dan 4G om een bruikbare schatting te geven. De maatregel in de huidige vorm is nog onvoldoende inzetbaar.
Technische randvoorwaarde: koppeling tussen VRI’s en TDI’s via NMS realiseren.
G. Lokale TDI-VRI koppeling
Deze toepassing functioneert goed in de PPA. Wel geven RWS en Amsterdam aan dat de koppeling niet past in de bedachte architectuur. Verzoeken tussen VRI’s en TDI’s behoren te lopen via de NMS’en.
Technische randvoorwaarde: de gebruikte koppeling tussen vri’s en tdi’s moet via NMS worden gerealiseerd.
H. Netwerkcoördinatie TDI-VRI (GNV)
De theorie is nog niet helemaal volwassen in de praktijk, maar de partijen zien wel kansen voor GNV. Met name PPA fase 1 heeft ons geleerd dat de afstemming heel precies komt. Wanneer teveel weggebruikers die niet langs de kiem hoeven, in de buffers belanden, dan is het totaalresultaat negatief.
De proeven in fase 2 (met name West en Noord) laten betere resultaten zien. Het instellen en fine-tunen van GNV is een intensief en complex traject.
Amsterdam geeft aan dat GNV niet altijd iets toe voegt. De ervaring van Amsterdam leert dat in sommige situaties een klassieke starre regeling meer effect geeft (denk aan S102, S112).
Organisatorische randvoorwaarde: Om GNV toe te passen is voldoende capaciteit van het juiste niveau (HBO+) nodig.
I. Trajectsupervisor
De trajectsupervisor is onbekend bij zowel RWS als Amsterdam. Met name Amsterdam geeft aan dat de tool technisch functioneerde, maar dat de meerwaarde beperkt was. Daarmee wordt de kosten-effectiviteit als onvoldoende bestempeld.
De reactie van PNH wijkt af. De trajectsupervisor is, samen met de Green time broker, het kruispunt / overstaan algoritme en het gebruik van het NMS voor de aansturing VRI/TDI een bewezen product. Het beeld van PNH is, dat dit cluster aan maatregelen uitrolbaar is op andere locaties en dus volwassen.
J. Real time netwerkregeling verkeerslichten
Amsterdam geeft aan dat ze wel kansen ziet voor dit deelproduct. Wel wordt aangegeven dat het product nog niet productierijp is. Binnen de scope van de haalbaarheidsstudie moet geconcludeerd worden dat het product nog niet toepasbaar is. Amsterdam geeft aan dat ze wel behoefte heeft aan een pilot op dit vlak.
Rijkswaterstaat geeft aan geen beeld te hebben van het product, deze wegbeheerder heeft immers geen VRI’s in het PPA-gebied.
PNH heeft gekeken naar IMflow (Dynniq), dit is een product met dezelfde functionaliteit zoals beproefd in de PPA Noord.
K. Cluster Green time broker – kruispunt / overslaan algoritme / gebruik NMS voor aansturing VRI/TDI / Databus A10 Noord / Trajectsupervisor
Dit cluster aan maatregelen is in de PPA-Noord ontwikkeld en is technisch en operationeel inzetbaar op andere locaties. De PNH geeft aan dat de investeringskosten voor de PPA-Noord fors waren, waarmee de terugverdientijd uitkomst op circa 7 jaar. De verwachting is, dat bij een verdere uitrol de kosten omlaag gaan en dat de terugverdientijd hierdoor wordt verkort.
De provincie geeft aan dat de assets wel een bepaalde intelligentie moeten hebben voordat ze ingezet kunnen worden. Sommige verkeerslichten in Amsterdam en verkeerslichten bij andere gemeenten zitten niet altijd op dit gewenste niveau. Om te bepalen of het cluster aan maatregelen toegepast kan worden zal eerst deze check moeten worden uitgevoerd. Het intelligent maken van de VRI´s is eveneens een optie. Dit is uiteraard van invloed op de kosten-batenanalyse.
De geïnterviewden van Rijkswaterstaat en Amsterdam geven aan ze onvoldoende bekend zijn met de resultaten van de PPA-Noord om uitspraken te doen over dit cluster aan maatregelen.
Technische randvoorwaarde: het cluster aan maatregelen is binnen de architectuur van de provincie succesvol ingepast. Inpassing van het cluster in de architectuur van Amsterdam en Rijkswaterstaat heeft nog niet plaatsgevonden.
Technische randvoorwaarde: Er is een toets nodig om te bepalen welk areaal nu al geschikt is voor GNV en welk areaal nog inzetbaar gemaakt moeten worden voor deze GNV-aanpak.
L. Gebruik Databus
De ervaring met de A10-west databus was, dat deze erg storingsgevoelig was. De databus heeft technisch gefunctioneerd, maar werd gezien als een houtje-touwtje constructie. Er is veel energie nodig van de beheerders om de databus werkend te houden. De beelden van de databus bij de PPA-Noord zijn beter. Alle partijen geven aan dat de databus onderdeel moet zijn van de architectuur, dus dat de databus moet hangen onder een NMS.
3.1.3 Toetsen aan de PPA-spin-offs
M. Knelpuntanalyse netwerk
In PPA is deze analyse eenmalig en voor de proef uitgevoerd. Bij uitrol van PPA onderdelen in andere regio’s is deze analyse vervolmaakt. De analyse is direct toepasbaar in het onderzoeksgebied van Amsterdam Bereikbaar of in andere regio.
N. Filegolfspeurder
De monitoring van filegolven is vanuit PPA via uitrol in de regio Utrecht gerealiseerd; het wegregelen van filegolven vergt nog ontwikkeling. Daarmee is het instrument nog niet direct inzetbaar voor de problematiek rond Amsterdam Bereikbaar.
Wel geven Rijkswaterstaat, PNH en Amsterdam aan behoefte te hebben aan de beschreven functionaliteit. Met meer kennis over de oorzaak van de file, kunnen meer gerichte maatregelen ingezet worden.
3.1.4 Overzicht volwassenheid PPA-producten en –spin-offs
Op basis van voorgaande paragrafen 3.1.2 (PPA-onderdelen) en 3.1.3 (PPA-spin-offs) is in onderstaande tabellen achtereenvolgens een overzicht gegeven van de volwassenheid van de verschillende PPA-producten en de PPA-spin-offs. Hierbij is een onderscheid gemaakt naar de technische haalbaarheid en de operationele haalbaarheid.
PPA-Producten | Technisch haalbaar? | Operationeel haalbaar? | Toelichting | ||||
Ja (volw.) | Misschien (i.o.) | Nee (onvolw.) | Ja (volw.) | Misschien (i.o.) | Nee (onvolw.) | ||
Basis op orde | X | X | Alleen A’dam heeft de basis nog niet op orde | ||||
Meetraaimanager | X | X | |||||
Kiemenspeurder | X | X | Het regelen met de Kiemenspeurder is bewerkelijk en duur. Het werken met (verschillende) kiemen in grotere netwerken is complex. | ||||
Toepassing wachtrijschatter met extra lussen | X | X | Het schatten van wachtrijen met lussen functioneert niet goed. De maatregel is zowel technisch als functioneel | ||||
onvolwassen en niet toe te passen voor vervolgvraagstukken. | |||
Toepassing wachtrijschatter met radardetectie | X | X | De radardetectie is nog niet in het reguliere beheer van het areaal opgenomen. Technisch en operationeel is de techniek wel volwassen om verder uit te rollen. |
Toepassing wachtrijschatter met Floating Car Data (FCD) | X | X | M.b.v. FCD worden de wachtrijen op dit moment met te grove data geschat, waardoor de betrouwbaarheid van de wachtrijen nu nog niet voldoende is. Nieuwe databronnen bieden kansen om dit te verbeteren. |
Lokale TDI-VRI koppeling (‘gecoördineerde aansluiting’) | X | X | De TDI’s regelen vaak niet op het goede moment, waardoor verkeerskundig gezien niet altijd het best geregeld wordt. Een koppeling tussen TDI en VRI past niet in de bedachte architectuur van GNV. Verzoeken tussen VRI’s en TDI’s dienen te lopen via de NMS’en |
Netwerk- coördinatie TDI- VRI (GNV) | X | X | Zowel technisch als functioneel is netwerkcoördinatie nog onvoldoende volwassen om rechtstreeks toe te kunnen passen. Het instellen en finetunen van GNV is een intensief en complex traject, wat het erg lastig maakt om optimaal te regelen. |
Trajectsupervisor | X | X | |
Real time netwerkregeling verkeerslichten | X | X | Deze maatregel is in de huidige vorm zowel technisch als functioneel nog niet productie klaar. Wanneer de maatregel verder door ontwikkeld wordt zijn er wel kansen. |
Green time broker (GTB) | X | X | Dit cluster aan maatregelen is voldoende volwassen gebleken voor toepassing binnen de architectuur van PNH (andere wegbeheerders nog niet getest). Voor toepassing op andere locaties dienen de VRI’s voldoende intelligentie te bevatten. |
Kruispunt- informatie / overstaan algoritme | X | X | |
Gebruik NMS voor aansturing VRI/TDI | X | X | |
Gebruik databus | X | X | De huidige databus is erg storingsgevoelig |
PPA-spin-offs | Technisch haalbaar? | Operationeel haalbaar? | Toelichting | ||||
Ja (volw | Misschien (i.o.) | Nee (onvolw. | Ja (volw | Misschien (i.o.) | Nee (onvolw. | ||
Knelpunt-analyse netwerk | X | X | De analyse is direct toepasbaar in vervolgvraagstukken. | ||||
Filegolfspeurder | X | X | Monitoring van de filegolven is reeds gerealiseerd. Het wegregelen van filegolven dient nog verder doorontwikkeld te worden voordat deze maatregel productie klaar is. | ||||
3.1.5 Overige bevindingen
* Rijkswaterstaat geeft aan dat zij veel landelijke systemen gebruiken. Om PPA-onderdelen toe te passen, zullen die onderdelen landelijk in beheer genomen worden.
* Rijkswaterstaat geeft aan dat PPA een goed platform is om proeven in te doen. De borging in de staande lijn is iets anders.
* Rijkswaterstaat geeft mee dat met name die onderdelen van PPA die de data verbeteren (meetraaimanager, kiemenspeurder) het meest kansrijk zijn.
* Amsterdam stelt dat je de ontwikkeling van PPA niet los kunt zien van andere ontwikkelingen. De markt is zelf bezig, 5G gaat komen en via C-ITS/Talking Traffic worden ontwikkelingen in gang gezet. Kijk niet naar sec. PPA maar naar het geheel aan kansen.
* PNH stelt dat innovatie in verkeersmanagement erg belangrijk is; PPA maakt het mogelijk dat innovaties plaatsvinden op verkeersmanagement.
3.2 Bevindingen over Xxxx Xxxxxx
In het rapport Xxxx reizen onderdelen haalbaarheidsstudie PPA, 26 mei 2017, heeft XTNT, enkele hoofdelementen uit de Slim reizen aanpak getoetst op haalbaarheid.
In het rapport van XTNT wordt de volgende driedeling gebruikt:
a. Projecten die succesvol beproefd zijn en één-op-éen elders inzetbaar;
i. Calender messaging
ii. Gesproken bericht
iii. Pushbericht
iv. (reis)informatieschermen
v. Sociale media
vi. Operationeel Mobiliteitscentrum OMC
vii. ‘Geofencing’
Deze categorie maatregelen kan ingezet worden voor de vraagstukken van Amsterdam Bereikbaar.
Bevindingen
Belangrijke vraag bij het inzetten van dit type maatregel is de veranderende verhouding tussen markt en overheid. Er is niet altijd sprake van het inzetten van maatregelen door de overheid, maar veel vaker van een samenwerking tussen partijen. Binnen de overheden is daarom behoefte aan andere operationele kennis: bijvoorbeeld voor Geofencing en Social Media moet afgestemd worden welke informatie gedeeld wordt en welke randvoorwaarden (geografisch) gelden.
Het inrichten van een Operationeel Mobiliteitscentrum (OMC) kost capaciteit, want het centrum moet bemenst worden. In het OMC wordt gewerkt met verschillende soorten data. Alle drie de wegbeheerders geven aan dat de architectuur hiervoor toegepast kan worden. Het is wenselijk dat de koppelingen tussen de overheden en de marktpartijen gaan lopen via de NMS’en. De beoogde koppeling naar de gebruiker loopt via een toepassing zoals de Mobility Portal.
b. Projecten die succesvol beproefd zijn maar niet één-op-één elders toepasbaar.
i. Actueel kaartmateriaal
ii. Slimme kaart
iii. Website met actuele reisinformatie.
iv. Mobility Portal
v. Virtuele DRIP’s
Deze categorie maatregelen zijn inzetbaar voor de vraagstukken van Amsterdam Bereikbaar, maar vergen nog een forse inspanning voordat ze meerwaarde bieden.
Bevindingen
Vanuit de losse projecten wordt gewinkeld in de maatregelcatalogus van Xxxx Xxxxxx. Dit type maatregel wint kracht, wanneer ze gecoördineerd ingezet worden voor een regio of een gebied.
Bovendien moeten de maatregelen locatiespecifiek gemaakt worden. De drie wegbeheerders zien hier een toegevoegde waarde voor Amsterdam Bereikbaar.
De Mobility Portal is primair gericht op de bezoekers van het Arena-gebied. Het vraagstuk voor Amsterdam Bereikbaar is breder, want de doelgroep is breder met woon-werkverkeer, studenten, evenementen en winkels. De techniek van de Mobility Portal is beproefd, maar of het ook werkt voor de bredere doelgroep is nog de vraag. Ook is nog niet duidelijk wie de eigenaar is van een Mobility Portal voor Amsterdam Bereikbaar.
c. Projecten die nog niet in de praktijk zijn toegepast maar die wel interessant zijn.
i. Common Operational Picture
ii. Verkeersvoorspeller
Deze maatregelen zijn nu nog niet toepasbaar. Mogelijk komen de maatregelen wel gedurende de periode van 10 jaar alsnog beschikbaar.
Alle wegbeheerders geven aan dat het belangrijk is om ook een pilot-omgeving te houden. De PPA heeft de afgelopen tijd deze rol vervuld. Vanwege de PPA was het mogelijk om dingen op straat uit te proberen. Advies van de wegbeheerders is, om naast de bewezen maatregelen parallel ook in te blijven zetten op pilots.
Het Common Operational Picture (COP) vervult een functionele wens van de wegbeheerders. In de interviews wordt aangegeven dat dit type producten bij meerdere marktpartijen beschikbaar is. De Provincie Noord-Holland gaat hierin het verste. Vanuit het programma iCentrale verkent de Provincie welke diensten te zijner tijd door marktpartijen ingevuld kunnen worden. Hierbij wordt onder andere gedacht aan het COP.
De drie partijen richten zich op het proactief verkeersmanagement. De huidige focus ligt erop om de levering van data te versnellen. Tools zoals de meetraaimanager zorgen ervoor dat de juiste data sneller gebruikt kan worden voor de inzet van maatregelen en voor adviezen. Maar dit blijft reactief verkeersmanagement. Pas wanneer een tool vooruit kan kijken, wordt proactief verkeersmanagement mogelijk. Diverse partijen werken aan dit type tools en hanteren hierbij verschillende strategieën. De ene strategie gaat uit van historische data en probeert die in te zetten om een betere inschatting van de toekomst te maken. Andere partijen richten zich op de floating-car-data, vanuit de telefoons of vanuit de auto’s zelf. De partijen geven aan de ontwikkelingen te volgen, maar nog geen concrete toepassing te zien voor Amsterdam Bereikbaar.
4 Match knelpuntenanalyse en kansen voor PPA
4.1 Archetypes
Arane heeft in haar analyse 14 knelpunten geïdentificeerd. Vanuit de PPA GNV zien zij 5 archetypes waarmee knelpunten aangepakt kunnen worden. De 5 archetypes zijn:
1A: HWN Kiem; een file waarbij de oorsprong van de file op het HWN ligt;
1B: Afrit Kiem; een file waarbij de oorsprong van de file ligt op de afrit / overgang naar het eerste kruispunt op OWN;
1C: Filegolven; een file die veroorzaakt wordt door een knelpunt elders, de filegolf komt langsgerold door het studiegebied.
1D: SWN Kiem; een file die veroorzaakt wordt door een te lage capaciteit op het OWN. 1E: Tunnel; specifieke regeldoelen, bijv. tunnelveiligheid.
Tabel kiemlocaties vs. Archetype kiemen (bron: Arane)
Het projectteam van de Haalbaarheidsstudie stelt vast:
1. Wat betreft de archetypes:
a. De ontwerpen 1 A (‘regelen op een kiem op de snelweg’) en 1D (‘regelen op een kiem op overige wegen’) zijn voldoende ontwikkeld (‘volwassen’) voor toepassing.
b. De ontwerpen 1B (‘afritprobleem’), 1C (‘Filegolf’) en 1E (‘Tunnelproblematiek’) vergen nog verdere ontwikkeling.
2. De ontwerpen 1A en 1D zijn (met name op basis van de evaluaties uit PPA West en PPA Noord voldoende effectief voor toepassing in een aantal van de huidige knelpuntsituaties in MRA. Hierbij is gekeken naar de knelpuntenanalyse uit het RTT en de knelpuntenanalyse uit Amsterdam Bereikbaar.
Vanuit de wegebeheerders worden enkele kanttekeningen gemaakt bij het gebruik van de verschillende archetypes op knelpunten:
a. Deze ontwerpen vergen implementatie van een aantal onderdelen; voor ‘de wachtrijschatter” zal hier radardetectie moeten worden toegevoegd.
b. In relatie met de duur van grote werkzaamheden in MRA moet nog een afweging worden gemaakt op basis van looptijd en terugverdientijd van kosten en baten. Op voorhand lijkt het niet zinvol GNV investeringen op locaties te doen gelijktijdig met werkzaamheden.
c. Er wordt voor de huidige knelpunten geen GNV toepassing voorzien op provinciale wegen in MRA.
d. Voor ontwerp 1D is per toepassing een afweging nodig met (iets minder innovatieve) producten van marktpartijen die beschikbaar zijn (bijvoorbeeld Imflow van Dynniq zoals in Provincie NH gebruikt en RTNT van Vialis zoals door gemeente Amsterdam wordt beproefd). Voor al deze toepassingen (vanuit PPA en met producten van marktpartijen) geldt dat er synergie is met invoering van iVRI vanuit Talking Traffic.
3. We hebben nog onvoldoende zicht op knelpunten in de toekomst gedurende de werkzaamheden. Met de analyse welke PPA-producten volwassen zijn, kan Amsterdam Bereikbaar zodra bekend is waar de knelpunten zitten, aan de slag met de beschikbare maatregelen.
4. De huidige operationele, technische processen en organisatie zijn voldoende voor de toepassing van PPA/GNV volgens voorgaande. Extra aandacht is nodig voor het regionale ketenbeheer. Dit is wel ingericht, maar functioneert nog niet voldoende. Er is wel extra aandacht nodig voor overdracht van de nieuwe kennis die nodig is voor verkeerskundig en technisch beheer en voor uitbreiding van capaciteit om de slagkracht/resultaatgerichtheid van de processen te vergroten. Toepassing van PPA/GNV ‘kan niet eventjes worden toegevoegd aan het bestaande werk’.
4.2 Kansrijkheid PPA op knelpunten
Arane heeft negen knelpunten geïdentificeerd. Vijf van deze knelpunten liggen op het HWN:
1. A10 Noord richting Xxxxxxxxx
0. A10 West richting De Nieuwe Meer
3. A10 Zuid richting Amstel / A2 Holendrecht
4. A10 Zuid richting De Nieuwe Meer
5. A1 richting Muiderberg
Op deze knelpunten lijkt een GNV-aanpak zoals in PPA in fase 2 toegepast op de A10 west zinvol.
Vier andere knelpunten op provinciale en stedelijke wegen zijn:
6. S106 (tussen A10 en S100)
7. S100 (tussen S105 en S108)
8. S108 (tussen A10 en S109)
9. N247 (richting Volendam)
Op deze knelpunten lijkt een GNV-aanpak zoals in PPA fase toegepast in de PPA-Noord zinvol. Aandachtspunt betreft de koppeling van de tools aan de systeemarchitectuur van de gemeente Amsterdam.
Voor de overige knelpunten geldt, dat de bewezen, volwassen tools niet direct geschikt lijken. Mogelijk zijn wel proeven met nieuwe tools mogelijk.
5.Conclusies technische en operationele haalbaarheid
Technische Haalbaarheid PPA-producten:
⮚ De PPA-producten Meetraaimanager, kiemenspeurder, wachtrijschatter met radardetectie, lokale TDI- VRI koppeling, de netwerkcoördinatie en het cluster met maatregelen uit de A10 Noord zijn technisch haalbaar.
⮚ Er is twijfel over de ‘realtime netwerkregeling verkeerslichten’
⮚ De toepassing van de wachtrijschatter met extra lussen of met floating-car-data (FCD) is nog niet haalbaar.
⮚ Basis op orde is altijd verstandig, maar Basis op orde PPA ligt soms een niveau hoger.
Technische Haarbaarheid Slim Reizen:
⮚ De projecten calender messaging, gesproken bericht, pushbericht, (reis)informatieschermen, sociale media, Operationeel Mobiliteitscentrum en geofencing zijn technisch haalbaar.
⮚ Van de projecten actueel kaartmateriaal, de slimme kaart, een website met actuele reisinformatie, een mobility portal en virtuele DRIP’s is aangetoond dat ze technisch inzetbaar zijn. Wel zijn voor deze maatregelen nog stappen nodig voordat ze effectief ingezet kunnen worden.
⮚ Het common-operational-picture en de verkeersvoorspeller bevinden zich in een pilotfase. Het is nog de vraag of ze gedurende de periode van Amsterdam Bereikbaar inzetbaar gaan worden.
6.Conclusies technische randvoorwaarden
Technische Randvoorwaarden PPA-producten:
1. De PPA-producten moeten passen in de architectuur van de organisaties. Dit is op orde voor de meetraaimanager en voor het cluster met maatregelen uit de A10 noord. Voor de overige producten moeten nog stappen gezet worden. Wanneer het product in de architectuur past, dan is het ook makkelijker om het beheer geregeld te krijgen.
2. Niet alle spullen zijn nu al geschikt om in PPA producten toe te passen. Met name de XXX’x zijn niet altijd intelligent genoeg. En niet alle VRI’s zijn uitgerust met lussen.
3. Koppeling van systemen van wegbeheerders (oa TDI’s en VRI’s) moeten lopen via de NMS’en.
4. De gebruikte FCD dient op korte trajecten (fijnmazig) beschikbaar te zijn.
5. Het cluster maatregelen van de PPA-Noord is ingepast binnen de architectuur van de PNH. Inpassing bij Rijkswaterstaat en Amsterdam is nog niet gerealiseerd
Technische randvoorwaarden Slim Reizen:
6. Het mobility portal richt zich op de evenementbezoekers. Kan eenzelfde type platform ook ingericht worden voor meerdere doelgroepen?
7. Passen het Operationeel mobiliteitscentrum en het mobility portal in de bedachte architectuur?
7.Conclusies Operationele randvoorwaarden
Operationele Randvoorwaarden PPA-producten:
1. De drie organisaties zijn ingericht voor de reguliere situatie. Extra inspanning zoals voor Amsterdam Bereikbaar is slechts ten dele voorzien;
2. Het regionale ketenbeheer functioneert nog niet naar wens. Er is wel behoefte aan een goed functionerend regionaal ketenbeheer.
3. Het finetunen van GNV is intensief en complex. De drie organisaties hebben onvoldoende kwaliteit in
huis om dit soort complexe inregelingen uit te voeren. De benodigde kennis zit slechts bij enkele, nu al druk bezette medewerkers.
4. Veel PPA-assets worden nog niet beheerd door de staande organisatie.
Operationele randvoorwaarden Slim Reizen:
5. De samenwerking tussen markt en overheid is aan het schuiven. Deze verschuiving is het meest zichtbaar bij de inzet van Xxxx Xxxxxx maatregelen. De huidige wegbeheerders zijn onvoldoende ingericht op deze andere ordening.
6. De bemensing van een OMC kost veel capaciteit. Deze capaciteit is niet geborgd in de staande organisaties.
7. De coördinatie van Xxxx Xxxxxx maatregelen is niet geborgd. Hier ligt een kans voor Amsterdam Bereikbaar.
8. De wegbeheerders geven aan dat men behoefte heeft aan een pilotomgeving die bestaat naast de staande organisatie. Zo kan de operatie te aller tijden doorgaan, maar komt er parallel ruimte voor nieuwe initiatieven.
Bijlage 1: Besprekingsverslag Rijkswaterstaat
BESPREKINGSVERSLAG
Bespreking | Datum |
Interview technische en operationele haalbaarheid PPA-Producten | 10 mei 2017 |
Aanwezig | Begin/Eindtijd |
Xxxx xx Xxxxx (RWS), Xxxx Xxxxxxx (RWS), Xxxxxxx xx Xxxx (Advin BV), Xxxxxxx | 11:00 – 12:30 uur |
Legius (Advin BV) | Plaats |
Afwezig | Verkeerscentrale Velsen |
n.v.t. | Projectnummer |
Kopie aan | INF1704400 |
Aanwezigen | Verslagnummer |
Opgesteld door | ……. |
Xxxxxxx Xxxxxx | Datum volgende bijeenkomst |
- | |
Onderwerp Interview technische en operationele haalbaarheid PPA-onderdelen |
Inleiding
Op woensdag 10 mei 2017 heeft een interview plaatsgevonden met Xxxx xx Xxxxx en Xxxx Xxxxxxx over de technische en operationele haalbaarheid van de onderdelen in de Praktijkproef Amsterdam (PPA) zijn ontwikkeld. Xxxx xx Xxxxx is operationeel verkeerskundige op de VC NWN en Xxxx Xxxxxxx is adviseur netwerkmanagement (assetmanagement) bij Rijkswaterstaat West-Nederland Noord.
Beiden zijn actief betrokken geweest bij de ontwikkelingen van de verschillende onderdelen binnen de PPA en zijn hierdoor goed op de hoogte van de technische en operationele haalbaarheid van deze onderdelen.
Visie RWS op Gecoördineerd Netwerkbreed Verkeersmanagement (GNV)
Binnen heel RWS (alle districten) is ingestemd met het doorvoeren van de Landelijke Regelaanpak. De Landelijke Regelaanpak is een methode voor het uitvoeren van regionaal verkeersmanagement op basis van een vastgestelde regelstrategie en referentiekader volgens de Gebiedsgericht Benutten Plus (GGB+) methode. De LRA biedt hiermee handvatten om op regionaal niveau (geheel netwerk) verkeersmanagement uit te voeren op basis van landelijk consistente regels.
De Landelijke Regelaanpak verschilt ten opzichte van het regelconcept dat in de PPA is ontwikkeld. De huidige onderdelen uit de PPA regelen maximaal op deelnetwerkniveau (hoofdzakelijk langer uitstellen van een file op een klein deel van het netwerk). In de PPA wordt dit gedaan door de instroom te beperken en uitstroom te bevorderen. De Landelijke Regelaanpak heeft daarnaast nog de optie om verkeer om te leiden.
Grootste verschil tussen PPA en LRA:
- PPA 🡪 regelt op basis van prioritering wegen (belangrijkste weg eerst)
- LRA 🡪 regelt op basis van ‘meest ernstige’ situatie (grootste knelpunt eerst)
Als het druk wordt/is gaan we over het gehele netwerk praten. De huidige onderdelen uit PPA regelen maximaal op deelnetwerkniveau (langer uitstellen van file op een klein deel van het netwerk).
Nr. | Naam | Beschrijving | Beoordeling / volwassenheid / toepasbaarheid |
1.1 | Basis op orde | Vooraleer verkeersmanagement kan worden toegepast, moet e staat van het operationeel, verkeerskundig en technisch beheer (de ‘basis’) van systemen en processen op orde zijn. | Functioneel / Technisch: De DRIP’s en camera’s van RWS werken over het algemeen goed (op orde), de TDI’s niet (niet geheel op orde). Technisch werken de TDI’s, maar verkeerskundig/functioneel is er groei mogelijk. De inzet van de TDI’s is nu niet optimaal (verkeerskundig): TDI’s worden vaak ingezet als ze niet nodig zijn, en niet ingezet als ze wel nodig zijn. Dit komt voornamelijk doordat de TDI’s lokaal regelen en geen rekening houden met het gehele netwerk (inschakelvoorwaarde). Organisatorisch: In het RTT wordt hierover gesproken. De visie van RWS is dat je een heel netwerk dient te optimaliseren vanuit één centraal punt doen (in Noord Holland zijn er nu 3 verkeerscentrales). Hier heb je scenario’s voor nodig die dat aan kunnen. De Landelijke Regelaanpak geeft hiervoor een goede methodiek (van lokaal naar netwerk). Dit wordt nu in gang gezet: - ‘Operationeel verkeerskundige’-laag is er klaar voor - De bestuurslaag moet capaciteit maken en ruimbaan maken voor de Landelijke Regelaanpak (geld en middelen beschikbaar stellen). |
Ambitie PPA: regelen op netwerkniveau Huidige stavaza PPA: regelen op deelnetwerkniveau (o.b.v. instroom beperken, uitstroom bevorderen). Het informeren/omleiden van verkeer (bijvoorbeeld d.m.v. DRIP’s valt buiten de scope van de PPA). Dit is volgens RWS een gemiste kans. Buiten de spits / rustige periode 🡪 valt rendement te behalen met PPA (lokaal / streng) In de spits / drukke periode 🡪 Landelijke regelaanpak (netwerk) Methodiek van Landelijke regelaanpak dient doorgevoerd te worden over het hele netwerk. (regelen op gehele netwerk = ambitie/visie van RWS) | |||
1.2 | Meetraai- manager | Verkeersgegevens die via NDW voor verkeersmanagement toepassingen beschikbaar komen, kennen een gemiddelde vertraging (‘latency’) van enkele minuten. Voor RWS snelwegen is door PPA een meetraaimanager ontwikkeld die de data ongeveer 20 seconden na de meetminuut beschikbaar stelt. Deze datalevering is bruikbaar voor andere PPA onderdelen (toepassing GNV bijvoorbeeld) maar kan ook worden gebruikt voor de inzet van regelscenario’s als basis voor verkeersvoorspellinge n, reistijdadvies en dergelijke. | Functioneel / Technisch: De hele keten van meten tot regelen / tonen op de weg duurt tussen de 4 á 7 minuten (DRIP-beelden zijn 7 minuten oud) In de huidige situatie kan hierdoor alleen reactief verkeersmanagement plaatsvinden. Terwijl RWS het ideaal beeld heeft om proactief verkeersmanagement toe te passen. Wanneer met de Meetraaimanager deze tijd kan worden verkort, is dat een groot pluspunt. Alle wegbeheerders dienen dezelfde data te meten, waardoor geëist wordt dat het door het NDW wordt ingewonnen. RWS wil graag zo real-time mogelijke / actuele data, met een goede kwaliteit. De Meetraaimanager zou hiervoor gebruikt kunnen worden, mits aan de punten wordt voldaan: - Functionele/technische eis: datalevering dient centraal via NDW te lopen (hetzelfde tijdstempel is nodig doordat de NMS’en van de 3 wegbeheerders (PNH, A’dam en RWS) aan elkaar gekoppeld zijn) - Functionele wens: zo snel mogelijk data beschikbaar (binnen minuut) Rechtstreeks inwinnen zit ook een vertraging in. Wegbeheerders moeten elkaars ijkwaarde/tijdstempel gebruiken doordat het netwerk door meerdere wegbeheerders wordt bemeten. Om ‘wildgroei’ van systemen/processen te voorkomen, dient iedereen de data op dezelfde wijze via NDW te laten lopen. Organisatorisch: Wanneer de data via het NDW beschikbaar komt, dan is het al georganiseerd (door het NDW). Dat is voor RWS voldoende. |
Bij problemen met betrekking tot de datalevering, dient NDW dit op te lossen. Verwacht effect: Ambitie RWS: proactief verkeersmanagement: - nu door handmatige tijdstriggers, voornamelijk bij evenementen waarbij de eindtijden bekend zijn (bijvoorbeeld einde voetbalwedstrijd ArenA). Nu voornamelijk reactief verkeersmanagement doordat ‘oude’ data wordt gebruikt (lang na-ijlen). Ook met de Landelijke Regelaanpak wordt reactief verkeersmanagement uitgevoerd: je wacht tot een triggerwaarde wordt over-/onderschreden en gaat daarna regelen. Meest simpele manier om meer rendement te behalen, is verkeersmanagement uit te voeren met zo actueel mogelijke data (geen/weinig vertraging in datalevering). | |||
1.3 | Kiemen- speurder | De kiemenspeurder is de link tussen netwerkanalyse waarin potentiële knelpunten worden bepaald en de beslissing of een regelaanpak metterdaad moet worden ingezet. De kiemenspeurder geeft real time aan of een knelpunt zal ontstaan en welk regeldoel moet worden bereikt om het knelpunt te voorkomen en/of te verminderen. In PPA is de kiemenspeurder op de snelweg toegepast en is gebleken dat gebruik van lussen als inputdata kan worden ingeruild voor FCD. | Functioneel / technisch: Xxxx en Xxxx hebben de Kiemspeurder in werking gezien (presentatie Xxxx Xxxxx en in RTT). De kiemenspeurder is een tool om een netwerk te analyseren (viewer). Hier zijn echter ook andere tools voor beschikbaar/in ontwikkeling. De vraag of de kiemenspeurder het meest geschikt resteert bij Xxxx Xxxxxxx en Xxxx xx Xxxxx. Ontbrekende functionaliteit: aan de voorkant niet kunnen instellen wat je eruit wilt krijgen. Bijv. wel MTM beelden, maar geen DRIP beelden. Ideaal beeld van RWS: viewer waarbij je van tevoren kunt instellen wat je wilt zien. De kiemenspeurder kan schokgolven m.b.v. kleuren inzichtelijk maken (pluspunt). Beeld waar kiemen zitten is bij RWS bekend (functionaliteit ‘waar zit de kiem’, heeft RWS reeds in beeld) Behoefte aan inzicht in herkomst-bestemmingen van verkeer ‘op de kiem’ (welk verkeer zit er op de kiem?). Dit zit nu niet in de Kiemenspeurder Xxxxx van maatregelen: wel H-B relaties opgenomen (welk verkeer heeft een relatie met de kiem?) |
Dit is de kiem, zoveel voertuigen er langs, relatie met aantal punten in netwerk, Voor de probleemanalyse van een vertraging is het handig om te weten wat voor ‘soort file’ je hebt (schokgolf, capaciteitsknelpunt etc.). De kiemspeurder kan hierbij helpen bij het zoeken naar / verklaren van de oorzaak van een knelpunt. Dit kan leiden tot de inzet van ander soortige maatregelen (beter en gerichter maatregelen inzetten). | |||
1.4 | Toepassing wachtrij- schatter met extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. In fase 1 PPA zijn daarvoor extra lussen aangelegd op de opstelstroken | Verrijking van je data, meer data tot je beschikking, waarmee je meer kunt regelen Groepje VRI’s meer werk kan doen FCD neemt toe. Lussen nu nog het meest betrouwbaar. Verwachting RWS is dat de lussen in de toekomst zullen verdwijnen omdat het ook een |
hele dure manier is. | |||
In de toekomst veel meer informatie uit de auto zelf (als sensor). | |||
Voornamelijk voor VRI’s interessant (PNH + A’dam) | |||
Wachtrijschatter met lussen op dit moment nog het meest | |||
doeltreffend. In de toekomst hoogstwaarschijnlijk voorbij gegaan | |||
door andere inwinsystemen (zoals FCD). | |||
1.5 | Toepassing | In PPA West en PPA | Ook in Utrecht toegepast (Xxxx) Met radardetectie zie je de auto’s echt komen aanrijden. Uitvoeringstechnische nadelen: - Voertuigcategorieën zijn moeilijk te bepalen; - Voertuigen worden snel afgedekt door andere voertuigen. In samenwerking met Fileradar zijn veel van de minpunten aangepakt (nu redelijk compleet / geeft goed beeld). Onduidelijk hoe volwassen het systeem is. Slecht weer, stilstaand verkeer? Dataverrijking |
wachtrij- | Noord (en bij uitrol | ||
schatter met | elders) wordt | ||
radardetectie | radardetectie | ||
toegepast om | |||
wachtrijen te bepalen. |
1.6 | Toepassing wachtrijschatt er zonder extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. Er is geprobeerd wachtrijen te berekenen zonder extra lussen aan te leggen en gebruik te maken van FCD als (extra) databron.. | Ervaringen met deze wachtrijschatter zijn RWS niet geheel bekend (PPA Noord, N516) Via via gehoord dat er een hoop gedoe was. Of de problemen veroorzaakt werden door de lussen of door de wachtrijschatter zelf is Xxxx en Xxxx niet duidelijk. Neutraal: snappen dat het gebruikt kan worden, maar of het ook daadwerkelijk nu gebruikt kan worden, dient bij PNH en A’dam nagevraagd te worden. |
1.7 | Lokale TDI- VRI koppeling (‘gecoördi- neerde aansluiting’) | Dit is het laagste niveau van gecoördineerd regelen in PPA: één toerit en één verkeerslicht werken samen om de instroom van verkeer van de stad naar de snelweg te beperken als dat nodig en zinvol is. Deze toepassing maakt de koppelkabel (die terugslag van wachtrijen op toeritten over kruispunten voorkomt) overbodig. | Functioneel / technisch: Aantal verbindingen zijn gelukt - Xxxx xxx Xxxxxxxxx? 🡪 beheerder van configuratie VRI en TDI. Werkt goed Nu via koperkabel verbonden 🡪 storingsgevoelig Niet zo ver is uitgewerkt om het optimaal te laten functioneren: - De koppeling met de TDI is geen uitgangspunt voor de regeling (regelprincipe) VRI-mensen bij A’dam zitten echt te regelen op de Amsterdamse VRI’s. Uitstroom beperken richting snelweg wordt nauwelijks gedaan. VDA10: Dummy TDI’s (alleen inwinnen, VRI’s uitstroom veranderen) 🡪 regelprincipe is niet volledig doorgevoerd Randvoorwaarde: dient bufferruimte aanwezig te zijn Vanuit de Landelijke Regelaanpak is de verbinding tussen VRI en TDI niet nodig, sterker nog: niet wenselijk, zowel de VRI als de TDI worden apart aangestuurd. Vanuit de LA wil je niet dat de VRI bepaalt dat de TDI uitgeschakeld dient te worden. Netwerkvisie: niet wenselijk vanuit netwerkregeling 🡪 koppelkabel achterhaald In de spits is de regelruimte zo beperkt dat de TDI heel snel uitgaat. |
Op rustige momenten of minder drukke momenten kan een VRI- TDI-koppeling wel een bijdrage leveren, doordat de wachtrij stroomopwaarts van de TDI minder snel terugslaat naar de VRI, waardoor langer gedoseerd kan worden. (bufferruimtes optimaal benutten). TDI gaat pas uit als de VRI te druk is. De vraag blijft hierbij of de TDI wel altijd op de juiste momenten staat te doseren. TDI-VRI koppelingen sinds VDA10 niet op veel locaties profijt van. Liggen er nog steeds. Gaat een analyse (door A’dam en RWS, vanuit RKCO (regionaal kortcyclisch onderhoud) maken van nuttige koppelingen. | |||
1.8 | Netwerk- coördinatie TDI/VRI (‘gecoördineer de netwerk- regeling’) | Als meer dan één (lokale) TDI-VRI koppeling worden gecoördineerd neemt de regelruimte toe en kan een groter regeldoel worden beantwoord. In deze netwerkcoördinatie wordt bufferruimte op de diverse plaatsen gelijkelijk verdeeld. | In principe is het een deelnetwerk waarop geregeld wordt. Inzicht in HB is heel gering Behoefte: op basis van FCD kun je actuele HB-matrices maken Mobility portal (Beter Benutten): maken gebruik van herkomst en bestemming. Coördinatie op de ring A’dam heeft erg weinig effect, doordat het verkeer slecht korte tijd op de ring zit, en hierdoor geen relatie met een kiem heeft (veel bestuurders die geen relatie hebben met de kiem worden in de wacht gezet). Instroom beperken naar een kiem door het coördineren van meerdere stroomopwaarts gelegen aansluitingen heeft hierdoor een beperkt effect. In het kader van de LA is het niet wenselijk om op deelnetwerkniveau te regelen. Lokaal of op een streng past wel binnen de LA. |
1.9 | Traject- supervisor | De trajectsupervisor optimaliseert regelingen van VRI's en TDI's in trajecten (met een richting). | Als het op NMS- niveau kan opereren dan is het prima. Wanneer je een netwerksituatie hebt, dan niet. Omleiden zit er niet in. De toegevoegde waarde van een trajectsupervisor is bij RWS niet bekend. Niet gezien in de praktijk: - Wellicht elementen in, die gebruikt kunnen worden Op dit moment een tussenproduct die niet direct inzetbaar is. Effect: |
Optimalisatie op klein deel binnen het netwerk (waarbij je niet alle instrumenten meeneemt die beschikbaar kunnen zijn). PPA noord is niet bij RWS bekend (rapportages niet gezien) | |||
1.10 | Real time netwerk- regeling verkeers- lichten | In fase 1 PPA is voor de trajectcoördinatie van VRI's op S102 gebruik gemaakt van een bestaande netwerkregeling van Vialis. Het is een alternatief voor trajectcoördinatie zoals bijvoorbeeld in PPA Noord toegepast (opm.: in regelgebied van PPA Noord is door Provincie NH een vergelijkbaar alternatief beproefd). | Geen VRI’s op de C- en D-wegen (belangrijke wegen) Geen mening, want weinig VRI’s in beheer (in PPA-gebied 0) Toegevoegde waarde: - Wanneer het rustig is, kan prioriteit gegeven worden aan bepaalde doelgroepen. Met de komst van de iVRI heb je in de toekomst veel meer mogelijkheden (doelgroep gestuurd, goederenvervoer, fietsers) Kansen wanneer je ruimte hebt om te prioriteren. De regelingen zijn voornamelijk op beleidsdoelen van gemeenten gericht. |
1.11 | Green time broker (GTB) | Deze module is in PPA Noord ontwikkeld om conflicterende aanvragen voor aanpassing van regelingen aan VRI automaten af te wikkelen (prioriteiten te stellen). Deze module is nodig in (deel)netwerken waarin de regelingen van VRI's op kruispunten in verschillende richtingen worden gecoördineerd. | PPA-noord: hoofdvraag was samenwerking tussen provincie en gemeenten, RWS aan de zijlijn. RWS heeft geen evaluatie gezien, dus kan niet over oordelen. |
1.12 | Kruispunt- informatie / overstaan algoritme | In PPA Noord is kruispunt informatie (in de databus) opgenomen als input voor regeleenheden. | RWS heeft geen evaluatie gezien, dus kan niet over oordelen. |
1.13 | Gebruik NMS voor | In PPA Noord is anders dan in fase 1 | NMS van de PNH is gebruikt om de verschillende elementen aan te sturen 🡪 volgens gewenste model van RWS. |
aansturing VRI/TDI | en PPA West de aansturing van VRI's en TDI's gedaan vanuit het NMS dat bij de Provincie in productie draait. Daarmee is deze aansturing binnen bereik van bestaande - in verkeerscentrales aanwezige systemen - gebracht. | Pluspunt! In de praktijk is gebleken dat het inderdaad kan (VRI’s en TDI’s aansturen vanuit NMS) Het liefst 1 NMS en 1 verkeerscentrale | |
1.14 | Gebruik databus | In PPA Noord is monitoring informatie verzameld in de bestaande databus die bij de Provincie onder het NMS "hangt". In PPA West en in fase 1 waren monitoring modules en regelmodules nog geïntegreerd in één systeemomgeving. | Wat de exacte functionaliteit van de databus is, is bij Xxxx Xxxxxxx en Xxxx xx Xxxxx niet bekend. Wanneer het zorgt voor dataverrijking is het altijd goed! Ook hiervoor geldt, dat wanneer het op netwerkniveau gebruikt dient te worden, het via het NDW dient te lopen. Bij lokaal/traject regelen hoeft het niet via het NDW, maar kan het rechtstreeks. |
🡪 RWS gebruikt veel landelijke systemen om uniform verkeersmanagement te kunnen doen.
🡪 Hoe gaan we het beheren (CIV) als het niet uniform is?
- CIV 🡪 beheer
- WVL 🡪 technisch / functioneel
🡪 PPA is losse tool die niet via de juiste weg is binnengekomen bij het CIV (storingen kunnen bijvoorbeeld niet worden bijgehouden).
🡪 RWS heeft de behoefte om scenario’s te kunnen beheren met de beschikbare tools.
🡪 Iedere regio heeft er zijn eigen visie over DVM. Als het via het RTT gaat lopen, wordt het een regionaal feestje
🡪 Offline tool
- Proof of technology 🡪 waarde bewezen
- Geconsolideerd systeem
🡪Hoe volwassen zijn de systemen?
🡪 Consolidatiespoor is RWS nu mee bezig
🡺 Bruikbare tools uit haalbaarheidsstudie 🡪 dan mogelijkheid om systeem binnen RWS als geconsolideerd systeem
🡪 Er dient behoefte aan te zijn. En dient landelijk gedragen te worden. Wanneer er geen dienstverlening van CIV op een product zit, dan wordt het beheer en onderhoud van de systemen erg moeilijk (ongewenst).
🡪 Geen enkele maatregel is volwassen Wel enkele maatregelen kansrijk.
🡺 Ook in WNZ en MN
🡪 Onderdelen/tools in ontwikkeling
- Filegolfspeurder
- Knelpuntanalyse netwerk
🡪 Haalbaarheid Wat lost het op? Wat kost het?
🡪 Toegepaste functionaliteit
🡪 PPA is een goed platform om proeven te doen,
🡪 Beoordelingscriterium: levensduur/techniek achterhaald
🡪 Performance netwerk = ontwerp (weg) + beheer/onderhoud + DVM + (Smart Mobility)
🡪 DVM heeft zijn maximum bereikt (spitsstroken)
🡪 Verkeersmanagers hebben meer middelden nodig, komt er niet omdat op DVM wordt bespaard en meer de focus op smart mobility wordt gelegd.
🡪 Onderdelen bruikbaar vanuit PPA
🡺 Data!!
o Meetraaimanager
o Kiemenspeurder plus! (incl. herkomst + bestemming)
Bijlage 2: Besprekingsverslag Amsterdam
BESPREKINGSVERSLAG
Bespreking | Datum |
Interview technische en operationele haalbaarheid PPA-producten | 23 mei 2017 |
Aanwezig | Begin/Eindtijd |
Xxxxx Xxxxx (Gemeente Amsterdam), Xxx Xxxxxxx (Gemeente Amsterdam), | 9:30 – 11:00 uur |
Xxxxxxx Xxx (Gemeente Amsterdam), Xxxxxxx xx Xxxx (Advin BV), Miranca | Plaats |
Seehöfer (Advin BV) | Gemeente Amsterdam |
Afwezig | Projectnummer |
n.v.t. | INF1704400 |
Kopie aan | Verslagnummer |
Aanwezigen | ……. |
Opgesteld door | Datum volgende bijeenkomst |
Xxxxxxx Xxxxxxxx | - |
Onderwerp Interview technische en operationele haalbaarheid PPA-onderdelen |
Inleiding
Op maandag 23 mei 2017 heeft een interview plaatsgevonden met Xxxxx Xxxxx, Xxx Xxxxxxx en Xxxxxxx Xxx over de technische en operationele haalbaarheid van de onderdelen die in de Praktijkproef Amsterdam (PPA) zijn ontwikkeld. Xxxxx Xxxxx is senior adviseur assetmanagement (technisch beheer), Xxx Xxxxxxx is (ontwerper functioneel beheer bij het team openbare ruimte en verkeersontwerp) en Xxxxxxx Xxx is senior adviseur verandermanagement.
Visie Gemeente Amsterdam op Gecoördineerd Netwerkbreed Verkeersmanagement (GNV): Technieken worden in toenemende mate volwassen. Tot ongeveer 10 jaar geleden waren er veel verkeersmanagementtechnieken. Amsterdam was daar goed mee bezig, maar wel met de beperkingen die
beschikbaar waren. Daar heeft Amsterdam het maximale uitgehaald. Nu komen er allerlei nieuwe technieken bij (bijv. sensoren en data) en zijn een aantal marktpartijen zeer nadrukkelijk gegroeid (bijv. Google).
Ook neemt de volwassenheid van de organisatie van de gemeente Amsterdam enorm toe; ze houden zich veel meer bezig met de vraag hoe er met grote hoeveelheden data steeds meer bereikt kan worden. Dat begon al bij een kwaliteitscentrale, wat verder wordt uitgebouwd. Er wordt nu in het data-lab van de gemeente Amsterdam een datacenter opgebouwd waar meerdere soorten verkeersdata naast elkaar gezet kunnen worden en met een generieke tool onderzocht kunnen worden.
De techniek heeft dus invloed en de markt laat zich laat zich nu ook veel nadrukkelijker zien, bijvoorbeeld veel meer publiek-private samenwerkingstrajecten (voorbeeld Talking Traffic).
Overheden zijn ook steeds meer bezig met de vragen:
- Hoe verhoud ik mij nu tot de markt?
- Wat doe ik zelf?
- Wat heb ik zelf in beheer?
- Wat besteed ik uit?
Dit is een zoektocht. De Gemeente Amsterdam vaart daar net een andere koers in dan bijvoorbeeld een Provincie Noord-Holland die eigenlijk zoveel mogelijk buiten de deur zet. De gemeente Amsterdam ervaart dat als vrij duur (private partijen zijn duurder dan ambtenaren) en de kritieke massa van de gemeente is hoog: Amsterdam alleen heeft al bijna 8 a 9% van alle VRI’s in Nederland (5500 in Nederland tegen 400 in Amsterdam). Door de grote schaal van Amsterdam kun je ook professionals aan je binden, die een perspectief hebben om beter te worden en te groeien in hun vakgebied. Dat is lang niet bij alle gemeenten en partijen het geval. De gemeente Amsterdam heeft ook aanzienlijk meer VRI’s dan RWS (70 of 80 VRI’s). RWS is daarmee zeer klein vergeleken met Amsterdam, terwijl RWS de grote partij is. En RWS houdt zich alleen bezig met autoverkeer, terwijl de bepalende factor voor de gemeente Amsterdam de overige modaliteiten zijn. Amsterdam heeft te maken met bezoekers, bewoners en bedrijven. Dit zorgt voor heel andere uitdagingen, zoals parkeren. Kortom.
Amsterdam trekt af en toe een vrij grote broek aan, maar dat is ook omdat ze te maken hebben met heel serieuze grootstedelijke problematiek die niet vergelijkbaar is met andere wegbeheerders, hooguit met Rotterdam.
Amsterdam liep altijd voor en had toentertijd ook het geld daarvoor. Vragen die de gemeente Amsterdam 1 a 2 jaar geleden al gesteld had, of een aandachtspunt (bijvoorbeeld een rode knop), daar is nu ineens vraag naar. Amsterdam heeft die ervaring. Ze merken dat ze, doordat ze vooroplopen qua kennis (in het ontwerpers-, beheerders- en gebruikersgedeelte), soms een beetje als een lastige partij worden gezien (en dat mag ook). Ze zijn heel blij met de partners bij RWS en de Provincie Noord-Holland. Er wordt veel opgetrokken met m.n. de Provincie Noord-Holland; ze delen kritieke infrastructuur. Er wordt verdere samenwerking voorzien met Provincie Noord-Holland, RWS en met marktpartijen, maar als overheid willen ze wel heel goed op de regiestoel gaan zitten.
De gemeente wil ook stappen zetten in zelfrijdend vervoer. Ze doet onderzoeken, bekijkt wat er nodig is, wat ze wil, wat wenselijk is; moet de stad zich aanpassen op zelfreizend vervoer of moet zelfreizend vervoer zich aanpassen aan de stad. Daar zijn ze ook mee bezig.
Nr. | Naam | Beschrijving | Beoordeling / volwassenheid / toepasbaarheid |
1.1 | Basis op orde | Vooraleer verkeersmanagement kan worden toegepast, moet de staat van het operationeel, verkeerskundig en technisch beheer (de ‘basis’) van systemen en processen op orde zijn. | De basis is op orde voor de Gemeente Amsterdam, maar niet voor PPA. Ze hebben 400 VRI’s staan die in principe op een goede manier zijn aangesloten (ongeveer 98%). Ook is het zo dat er op een aantal plaatsen een ‘starre’ groene golf is; die kruispunten zijn star geregeld zonder detectie. Voor de Gemeente Amsterdam is dat basis-op-orde. Voor PPA is echter detectie nodig, waardoor het ineens geen basis-op-orde meer is. Als je meer wilt met je gegevens, dan zullen er dus misschien aanvullende maatregelen nodig zijn en is de basis dus niet op orde. Dat zijn functionele eisen die je stelt om op een bepaalde manier te kunnen regelen op een GNV- achtige manier. Daarvoor is aanvullende data nodig, dat aanvullend ingewonnen moet worden en dat kan op verschillende manieren. |
1.2 | Meetraai manager | Verkeersgegevens die via NDW voor verkeersmanagement toepassingen beschikbaar komen, kennen een gemiddelde vertraging (‘latency’) van enkele minuten. Voor RWS snelwegen is door PPA een meetraaimanager ontwikkeld die de data ongeveer 20 seconden na de meetminuut beschikbaar stelt. Deze datalevering is bruikbaar voor andere PPA onderdelen (toepassing GNV bijvoorbeeld) maar kan ook worden gebruikt voor de inzet van regelscenario’s als basis voor verkeersvoorspellingen, reistijdadvies en dergelijke. | Functionele wens is om redelijk snel de data te hebben en dat is met de huidige middelen (zoals 4G) niet mogelijk. (Bij de Gemeente Amsterdam is het open en dat is nog slechter. Ze willen over naar een ander platform.) Eisen voor C-ITS worden niet gehaald met 4G. Dan zou overal in Nederland glasvezel gelegd moeten worden. Dat zijn andere investeringen. Bij C-ITS is het beeld dat ooit nog een keer 5G beschikbaar zou moeten komen en dat het daarmee misschien wel haalbaar is. Maar C-ITS draait nu en begin volgend jaar en 5G halen we nu nog niet. Meetraaimanager als een soort tussenstap, waarmee data sneller beschikbaar is? Meetraaimanager is te traag en niet voldoende voor C-ITS, maar wel voor PPA en de interpretatie van de vernieuwde landelijke regelaanpak. Voor C-ITS is 5G of glasvezel nodig. Dan zou heel Nederland moeten ‘verglassen’. Drie niveaus: 1. Oude niveau met data na 5 tot 7 minuten 2. Meetraaimanager versnelt het en daarmee kunnen regelaanpak achtige toepassingen gedaan worden 3. Voor C-ITS schieten bovenstaande systemen tekort en zijn andere (snellere) systemen nodig (glasvezel of 5G – waarschijnlijk niet binnen 2 jaar) Meetraaimanager wordt niet gebruikt door de Gemeente Amsterdam. |
1.3 | Kiemen- speurder | De kiemenspeurder is de link tussen netwerkanalyse waarin potentiële knelpunten worden bepaald en de beslissing of een regelaanpak metterdaad moet worden ingezet. De kiemenspeurder geeft real time aan of een knelpunt zal ontstaan en welk regeldoel moet worden bereikt om het knelpunt te voorkomen en/of te verminderen. In PPA is de kiemenspeurder op de snelweg toegepast en is gebleken dat gebruik van | Techniek: Doet het, maar vooral een instrument voor RWS (die op snelwegen aangeeft waar de kiem zit). Toepassing van de techniek: Een goed regelconcept op de kiem is de vraag. Op basis van de kiemenspeurder VVU’s verminderen is nog heel moeilijk. Want bij te vroeg managen, wordt verkeer gehinderd en die VVU’s worden niet meer teruggewonnen doordat je een file voorkomt. Hierbij worden ongeloofwaardige situaties gecreëerd. Alleen in de marge (helemaal aan het begin en helemaal aan het eind van een file) kun je nog wat smoothing van de file veroorzaken, maar dat is het maximale wat kan. De concepten van PPA zijn wel redelijk uitgedacht. Fase 1 had een negatieve evaluatie. Fase 2 is het wat verder uitgedacht. Xxxxx en Xxx hebben zich vooral met fase 1 beziggehouden en |
lussen als inputdata kan worden ingeruild voor FCD. | zijn niet zo op de hoogte van fase 2. Xxxxxxx is juist meer met fase 2 bezig geweest en minder met fase 1. Het instrument kiemenspeurder is volwassen, maar het gebruik ervan nog niet; die behoeft nog ontwikkeling. En het is nogal bewerkelijk. Het is ook nog eens duur (constant ook alle sensoren werkend en in de lucht houden). Het netwerk regelen is nog niet bereikt; dat is nog niet volwassen m.b.t. de kiemenspeurder. | ||
1.4 | Toe- passing wachtrij- schatter met extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. In fase 1 PPA zijn daarvoor extra lussen aangelegd op de opstelstroken | Wachtrijschatters met lussen werken niet (=uitkomst fase 1) en het was duur. |
1.5 | Toe- passing wachtrij- schatter met radar- detectie | In PPA West en PPA Noord (en bij uitrol elders) wordt radardetectie toegepast om wachtrijen te bepalen. | Werkt behoorlijk goed, maar kost ook geld. Overal radar aan moeten brengen + beheer is kostbaar. Extra beheer, hoe hebben jullie dat onderling geregeld? Vanaf het allereerste moment heeft de Gemeente Amsterdam beheerafspraken met RWS en de basis die toen gelegd werd, de ‘nieuwe’ basis-op-orde, werd ook beheerd. De koppelfactor werd ook gedefinieerd: tot waar ben je verantwoordelijk als gemeente en tot waar RWS. Heel basaal, de verantwoordelijkheid van de gemeente A’dam begint bij de automaat en verspreid zich dan over alle infra die daar nodig voor is (filelussen, koplussen, detectie, enz.). De verantwoordelijkheid van RWS begint bij de koppelkabel (tussen de automaat van de gemeente en de TDI- automaat) en daar vandaan weer alle infra voor de TDI. Vervolgens is de gemeente A’dam ongeveer 5 jaar geleden teruggegaan naar verzorgingsniveau ‘sober’, waarin bezuinigd moest worden. Daarbij werd de keus gemaakt dat een VRI er is voor het regelen en niet om PPA te ondersteunen. Dus filelussen die kapot gingen werden wel bewaard, maar die werden niet actief hersteld. Die konden weer hersteld worden op het moment dat er weer een project aan gekoppeld werd. Het is niet vaak voorgekomen dat een filelus heel lang stuk was, maar het was wel een gegeven dat af en toe filelussen defect waren. In de periode tussen het opleveren van PPA fase 1 en nu praat de gemeente A’dam met enige regelmaat met de beheerafdeling van RWS. Het beheer is echter tot de dag van vandaag nog steeds niet op orde, aan zowel de kant van RWS als A’dam. Dat is ontstaan vanaf het moment dat het TDI-contract veranderd is en is overgegaan op een andere beheerder. Alles wat op en langs de weg stond was één contract, incl. de TDI’s. Hierdoor ging de groenvoorziening de TDI’s onderhouden. Dit is niet goed |
voor het beheerproces. Tot op de dag van vandaag is het beheer van de TDI’s/VRI’s (het lokale systeem) niet goed geregeld!! En helpt de ketenbeheergroep die is opgericht hier in de regio? Nee, dat helpt niet. Technisch doen de TDI’s het, maar verkeerskundig werken ze niet. | |||
1.6 | Toe- passing wachtrij- schatter zonder extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. Er is geprobeerd wachtrijen te berekenen zonder extra lussen aan te leggen en gebruik te maken van FCD als (extra) databron. | Op de snelweg gebruikt, maar niet op het onderliggend wegennet. Bij Xxxxxxx bekend dat FCD getracht is te gebruiken als wachtrijschatter, maar dat dat matig werkte. Met leverancier Imrix waren het nog best lange trajecten (400 a 500 m). Daarmee ook een grove schatting van een wachtrij. Ondanks interpoleren e.d. werkte het slecht. Nu sinds een tijdje beschikking over FCD van B-Mobile met 50 m trajecten. Dat is al een stap vooruit, alhoewel in A’dam dat alweer het volgende verkeerslicht is. Maar op een toerit naar een snelweg kan het wel nuttig zijn. Imrix 400 m -> heeft niet gewerkt, is te onnauwkeurig B-Mobile 50 m -> Volwassenheid is nog niks over te zeggen; moet nog getest worden. Niet heel veel hoop op… |
Conclusie: Xxxxx heeft niet gewerkt; B-Mobile is een interessante nieuwe proef. | |||
Spannend is de data uit de mobieltjes zelf (hebben ze nog niet): Bij 4G 67m nauwkeurig; prima voor HWN, voor stedelijk nauwelijks bruikbaar Bij 5G 5 m nauwkeurig: voor bepalen reistijden en wachtrijen goed, maar niet goed genoeg voor regelen | |||
Xxx geen directe toepassing mogelijk | |||
1.7 | Lokale TDI-VRI kop- peling (‘gecoör- dineerde aan- sluiting’) | Dit is het laagste niveau van gecoördineerd regelen in PPA: één toerit en één verkeerslicht werken samen om de instroom van verkeer van de stad naar de snelweg te beperken als dat nodig en zinvol is. Deze toepassing maakt de koppelkabel (die terugslag van wachtrijen op toeritten | Koppelkabel is wel nodig. Koppelkabel heeft twee functies: 1. wordt gebruikt voor gecoördineerd regelen, en 2. heeft een signaalfunctie waarmee beide systemen met elkaar communiceren. Bij PPA praten TDI en VRI met elkaar zonder koppelkabel. Dit geldt voor het regelen, maar voor de instandhouding van het systeem is het nodig dat ze elkaar zien. De gemeente Amsterdam denkt ook dat de koppelkabel eigenlijk niet matcht met hoe er gecommuniceerd zou moeten worden via NMS bovenover op een hoger niveau. Als de juiste stappen |
over kruispunten voorkomt) overbodig. | ondernomen worden, kan het allemaal bovenover geregeld worden. Maar er gaat ergens iets fout, is niet helemaal goed ingeregeld bij de gemeente A’dam. Hoe ver zijn we er in? Er gaat veel bovenover op dit moment, maar het regelen expliciet niet. Het is niet bovenover geregeld in A’dam, omdat het onderdoor nog werkt -> niet dubbel regelen; is zinloos. Het huidige systeem werkt prima. Er worden ook geen nieuwe koppelingen meer gelegd. Mocht de gemeente A’dam van het beheer van de koppelkabel af willen en over willen gaan op alles bovenover dan zal het een nieuw project worden en wordt het binnen de gemeente gezamenlijk opgepakt, maar het heeft zeker geen prioriteit. | ||
1.8 | Netwerk- coördi- natie TDI/VRI (‘gecoör- dineerde netwerk- regeling’) | Als meer dan één (lokale) TDI-VRI koppeling worden gecoördineerd, neemt de regelruimte toe en kan een groter regeldoel worden beantwoord. In deze netwerkcoördinatie wordt bufferruimte op de diverse plaatsen gelijkelijk verdeeld. | Ervaring A10 west: bij het te precies doen worden te veel mensen gehinderd. Het verlies is groter dan de winst die je haalt met het regelen. Dat ligt gevoelig. De theorie is nog niet helemaal volwassen in de praktijk, maar er zijn wel kansen met nieuwe ontwikkelingen zoals C-ITS. Pluspunt C-ITS: beter weten wat de herkomst en bestemmingen zijn, en daarmee of er nu verkeer gehinderd wordt dat er niks mee te maken heeft. Potentieel gaat dit helpen, maar dat moeten ze nog in de praktijk zien (het is nog niet aangetoond in de praktijk). In theorie werkt het. Qua investeringen in tijd en geld is het vrij fors om het effect eruit te halen, en volgens het beheerplan; dit is een van de allerduurste factoren. PPA wordt door de gemeente A’dam vooral gezien als een proeftuin en daarom wordt het ook nog niet gezien als toepasbaar. En als extra punt wordt ook aangegeven dat een nieuw systeem qua kosten niet opweegt tegen de huidige starre regelingen, ook al zijn deze misschien iets langzamer. |
1.9 | Traject- super- visor | De trajectsupervisor optimaliseert regelingen van VRI's en TDI's in trajecten (met een richting). | Nauwelijks effect van ondervonden. Daar gaat het mank op de kosten/batenanalyse; niet veel winst gezien. Technisch ok, maar de positieve effecten waren niet zichtbaar. Openbaar vervoer en wachtende voetgangers, dat werkt wel. Omdat hij optimaliseert, ga je altijd iemand benadelen. Het was heel moeilijk om binnen de kaders te blijven van het vorige stelsel (bijv. maximale en gemiddelde wachttijden). |
1.10 | Real time netwerk- regeling verkeers- lichten | In fase 1 PPA is voor de trajectcoördinatie van VRI's op S102 gebruik gemaakt van een bestaande netwerkregeling van Vialis. Het is een alternatief voor | PPA Noord werkt voor het individu soms niet goed (veel vertraging is persoonlijke ervaring). Verschil individu en collectief is wat dat betreft moeilijk aan te geven. GNV-concept: dat je als individueel vertraging op kan lopen om als collectief minder VVU’s te hebben. |
trajectcoördinatie zoals bijvoorbeeld in PPA Noord toegepast (opm.: in regelgebied van PPA Noord is door Provincie NH een vergelijkbaar alternatief beproefd). | Betrouwbaarheid van alles is moeilijk. Zijn de instrumenten allemaal even geschikt om bv. al die VVU’s daadwerkelijk boven water te krijgen? Evalueren is heel moeilijk. Ook daar zitten marges in. Persoonlijke ervaring kan stiekem gestoeld zijn op veel meer dan we zouden denken, omdat de meetgegevens wellicht ook nog misleidend zijn. Dat is ook zichtbaar bij FCD vs. camera-data. Er wordt gezegd dat FCD op lange trajecten prima camera-data kan vervangen, want het is ongeveer even betrouwbaar. Maar er is nog nooit gekeken op een beeldcamera welke van de twee nou het meest klopt (validatie). De echte validatieslag is visueel, ter plekke er gaan staan en tellen. Zelfs dan al een versimpeling van de werkelijkheid: wat tel je dan? Accepteren we ‘garbage in, garbage out’? We accepteren dat de meetgegevens die we ontvangen feilloos zijn, maar dat is als je dat gaat testen eigenlijk nooit zo. Voertuigafhankelijke regelingen kunnen we gewoon zien op straat; dat werkt. Maar met grote getallen is dat een stuk lastiger te bepalen. Daar zit de zorg (kanttekening bij alles wat ze doen). Stukje innovatie is belangrijk. Door vaker toe te passen, te toetsen en daadwerkelijk in Amsterdam Bereikbaar te doen worden nieuwe dingen geleerd. Dan kan er ook beter gezegd worden wat wel en wat niet werkt. Maar niet iets niet doen, omdat je het niet aan kunt tonen. Dat is kansen weggooien. Het is wel logisch om misschien 80% bewezen maatregelen te willen neerzetten, maar een deel voor innovatie (omdat je redelijke kansen ziet voor de middellange termijn) is ook belangrijk. Hierdoor wordt je beter. Amsterdam Bereikbaar heeft gezegd alleen te willen werken met bewezen maatregelen. Daar kun je vraagtekens bijzetten. Een stukje innovatie zou niet zo gek zijn. Groot winstpunt van de PPA: dat je elkaar hebt gevonden om dit te kunnen doen. Ook het proces om met elkaar samen te werken. | ||
1.11 | Green time broker (GTB) | Deze module is in PPA Noord ontwikkeld om conflicterende aanvragen voor aanpassing van regelingen aan VRI automaten af te wikkelen (prioriteiten te stellen). Deze module is nodig in (deel)netwerken waarin de regelingen van VRI's op | Niet gebruikt, alleen in PPA-noord. Zou nuttig kunnen zijn. Xxxxxxx geeft aan dat er een intense behoefte is aan de GTB, maar dat heeft vooral te maken met C- ITS. Hij voorziet op langere termijn situaties waarbij VBS zelf dingen ziet, het netwerkmanagementsysteem dingen wil, de C- ITS applicaties prioritering gaan aanvragen voor bepaalde doelgroepen en met Socrates krijgen we de automotive industrie die ook wat wil. Die VRI krijgt straks uit 5 richtingen aanvragen en het gaat de gemeente A’dam om de functionaliteit, en een entiteit moet iets maken van al die verschillende verzoeken en |
kruispunten in verschillende richtingen worden gecoördineerd. | berichten en uiteindelijk een bepaalde richting zoveel groen geven. Nu is het allemaal nog enigszins te managen, maar bij dit onderdeel is het lastig = de missing link in C-ITS. (Afweging maken tussen al die belangen, en daar kan zo’n instrument goed bij helpen) | ||
1.12 | Kruispunt infor- matie / over- staan algoritme | In PPA Noord is kruispunt informatie (in de databus) opgenomen als input voor regeleenheden. | Bij PPA Noord heeft de gemeente A’dam bij één kruispunt een databus gecreëerd om PPA Noord alvast van informatie te voorzien (V-Log): een technische oplossing om betere informatie te hebben voor PPA Noord. Die werkt ook. In C-ITS gaat dat ook terugkomen. |
1.13 | Gebruik NMS voor aan- sturing VRI/TDI | In PPA Noord is anders dan in fase 1 en PPA West de aansturing van VRI's en TDI's gedaan vanuit het NMS dat bij de Provincie in productie draait. Daarmee is deze aansturing binnen bereik van bestaande - in verkeerscentrales aanwezige systemen - gebracht. | Heeft de gemeente hele ruime ervaring mee. Het heeft ook haken en ogen. Eén keer meegemaakt (bij de S114) dat er een uit-bericht was verstuurd wat niet werd ontvangen, waardoor de VRI veel te lang in een bepaalde stand bleef staan. Er zouden vraagtekens gesteld moeten worden wanneer een VRI erg lang in een bepaalde stand blijft staan. De koppeling naar RWS en Provincie: Dat gaat uitstekend. Enige issue is dat de gemeente een 24/7 verkeersleiding heeft, die aardig getraind is om NMS te gebruiken. Ze willen geautomatiseerd werken, maar er moet altijd een verkeersleider bij zijn die weet ‘ok, ik ben actief iets aan het doen. Wil ik dit?’ Je kan het rechtstreeks koppelen dat het automatisch gaat, maar het advies is om dit handmatig te doen. De adviezen zijn door de gemeente volledig herschreven. De verkeersleiding krijgt veel meer informatie over de interne vraagstukken. Ze bepalen aan de hand van de specifieke informatie welke VRI ze aan willen sturen. Met de DVM-exchange verzoeken voorziet het systeem daar niet in. Je krijgt 1 regel tekst en daar moet je het mee doen. -> stukje ontwikkeling [NMS -> verkeersleiding (zegt ja, dan pas naar …) -> VBS] RWS is ook 24/7 en de Provincie niet. Is dat een probleem? Ja, dat is lastig. En wat ook opgemerkt wordt bij RWS is dat ze soms NMS helemaal niet voor zich hebben staan; het staat regelmatig niet eens aan. Is daar een ondergeschoven kindje, maar bij de gemeente A’dam staat hij altijd voorop. |
1.14 | Gebruik databus | In PPA Noord is monitoring informatie verzameld in de bestaande databus die bij de Provincie onder het NMS "hangt". In PPA West en in fase 1 waren | A10 west had heel veel verstoringen in het begin. Op een gegeven moment ging het goed, maar het heeft behoorlijk wat aandacht gevergd aan de kant van de gemeente om de databus in stand te houden en vervolgens aan de kant van Technolution om de data die binnen kwam ook goed te verwerken. Het was een ‘houtje-touwtje’ constructie. |
monitoring modules en regelmodules nog geïntegreerd in één systeemomgeving. | Wat is jouw wens? Geen ‘houtje-touwtje’ constructie, maar iets a la PPA Noord. De gemeente heeft er wel eentje nodig. Ook omdat er in de komende 1,5 jaar vier projecten gerealiseerd gaan worden waar de databus een integraal onderdeel van uitmaakt. Voor de Amsterdamse oplossing voor C-ITS, het crowd-monitoring systeem en het camerasysteem is de databus een oplossing. De databus is er momenteel niet; de gemeente gaat misschien gebruik maken van de databus van de Provincie Noord-Holland. Wellicht nemen ze er zelf eentje. Maar dat er eentje komt binnen 1,5 jaar is wel een aan zekerheid grenzende waarschijnlijkheid. En dan kan er ook weer van geleerd worden. Welk product er gebruikt gaat worden is nog niet bekend. |
🡪 N.a.v. 1.4 (nieuwe innovatie) -> nieuwe techniek voor wachtrijschatters is glasvezel. Als je een glasvezelkabel hebt gelegd voor de dataoverdracht, schijn je daar ook op basis van de trillingen die op de glasvezel losgelaten worden wachtrijen te kunnen schatten. Dat wil de Gemeente Amsterdam wel proberen.
🡪 Bij C-ITS zijn er een heleboel ontwikkelingen, maar wat er mist is dat C-ITS voorrang belooft voor iedereen (fietsers, voetgangers, …) maar dat er niet duidelijk is hoe dat gedaan wordt. De gemeente Amsterdam geeft aan: met beleidskeuzes, maar die stap ontbreekt nu. De gemeente is daar bewust van, maar er zijn een heleboel andere partijen die zich alleen maar bezighouden met het klaarmaken van de techniek en die zich niet bezighouden met dit vraagstuk.
In de aanpak van Amsterdam is bewust een stukje evaluatie meegenomen. Ze hebben het er niet over gehad hoe ze het gaan doen.
Bijlage 3: Besprekingsverslag Provincie Noord- Holland
BESPREKINGSVERSLAG
Bespreking | Datum |
Interview technische en operationele haalbaarheid PPA-producten | 29 mei 2017 |
Aanwezig | Begin/Eindtijd |
Xxx Xxxxxx Xxxxx (PNH), Xxxxxxx Xxxxxx (PNH), Xxxxxxx xx Xxxx (Advin BV), | 11:00 – 12:30 uur |
Xxxxxxx Xxxxxxxx (Advin BV) | Plaats |
Afwezig | Provincie Noord-Holland, |
n.v.t. | Haarlem |
Kopie aan | Projectnummer |
Aanwezigen | INF1704400 |
Opgesteld door | Verslagnummer |
Xxxxxxx Xxxxxxxx | ……. |
Datum volgende bijeenkomst | |
- | |
Onderwerp Interview technische en operationele haalbaarheid PPA-onderdelen |
Inleiding
Op maandag 29 mei 2017 heeft een interview plaatsgevonden met Xxx Xxxxxx Xxxxx en Xxxxxxx Xxxxxx over de technische en operationele haalbaarheid van de onderdelen in de Praktijkproef Amsterdam (PPA) die zijn ontwikkeld.
Xxx Xxxxxx Xxxxx is (1) werkzaam op de afdeling verkeersmanagement en is (2) beheerder m.b.t. verkeersmanagementonderdelen. Xxx Xxxxxx is bij de afdeling verkeersmanagement betrokken geweest bij voorbereidingsfase van fase 2 (definitiefase). De provincie heeft heel hard ingezet op PPA-noord. In fase 1 was een stuk areaal namelijk een provinciaal areaal. Bij fase 2 was een harde eis van de provincie dat ze mee wilden doen aan PPA en het ook wilden beproeven in de praktijk. Daar is PPA-noord uit voort gekomen. Xxxxxx Xxxxxxxx (zit in hetzelfde team; is geen geïnterviewde) heeft heel veel gedaan met PPA-zuidoost: uitwerking fase 2 en zit nu voor een deel bij de discussies over fase 3.
Xxxxxxx Xxxxxx is adviseur verkeersmanagement. Heeft diverse rollen gehad binnen de Provincie. Zit inhoudelijk heel erg op de VRI. Voor PPA-noord als kernteamlid betrokken geweest; bezig geweest met het ontwikkeltraject van de PPA-module in de VRI en het realiseren van de connectie met de centrale module. Is bekend met alle onderdelen binnen PPA-noord.
Visie Provincie Noord-Holland op Gecoördineerd Netwerkbreed Verkeersmanagement (GNV):
De staten hebben gezegd dat ze koploper willen zijn in Smart Mobility en dat ze willen excelleren in verkeersmanagement (vanuit Smart Mobility insteek). Drie speerpunten:
1) Xx Xxxxxxxxx wil actief betrokken wil zijn bij nieuwe ontwikkelingen in Smart Mobility. Ze stelt zich graag beschikbaar als partner in het beproeven van nieuwe technieken. Er is ook extra geld toegekend aan Smart Mobility.
2) De Provincie heeft een vigerend beleidskader “Verder met verkeersmanagement” met ambitieuze verkeerskundige doelen. Het wordt nagestreefd om ze te halen. Op basis daarvan zijn een aantal ontwikkelsporen gezet: verknopen van modaliteiten, verbeteren van informatie, verhogen van de betrouwbaarheid van de reis, enz. Wat betekent dat concreet over samenwerking? Daar staat de Provincie heel open in. Ze willen graag samenwerken met partijen die een bijdrage kunnen leveren aan het halen van die ambities; ook met collega-(vaar)wegbeheerders.
3) Bij het programma iCentrale zijn ze aan het verkennen of ze het niet willen uitvragen als ‘diensten’ i.p.v. als ‘producten’. Verkennen of ze niet aan de markt een uitvraag willen doen voor een dienstendoorstroming op de provinciale wegen, om die te leveren i.p.v. dat ze met hun eigen centrale exporteren, eigen systemen hebben enz. Daarin is de Provincie anders dan de Gemeente Amsterdam en RWS; zij zijn meer bezig met eigen mensen, eigen spullen terwijl de Provincie meer bezig is met verkennen of het anders en efficiënter kan.
Voorbeeld van een concreet project dat daaruit ontstaat:
Opdracht om 48 VRI’s om te bouwen van een normale VRI naar een i-VRI. i-VRI is een nieuwe opengezette inhoudelijke architectuur, waarin je invulling kunt geven aan de eerder genoemde doelen (innovatie bij het regelen van het verkeer). Link met PPA is iets heel specifieks; dat is niet een used-case die vanuit Beter Benutten naar voren komt, maar gekeken naar de opbouw van de structuur en de toepassingen daarvoor dan zijn er wel een aantal overeenkomsten. In dit project wordt gekeken welke sterke punten van PPA hergebruikt kunnen worden bij de ontwikkeling van i-VRI, en of er toepassingen voor zijn. (Is niet alleen vanuit PPA gedreven).
Ze willen dingen uitrollen en door innoveren.
Ze wilden PPA-noord, omdat ze graag ervaring wilden opdoen met de interactie tussen HWN en OWN, instroom en uitstroom, en hoe dit goed te organiseren. Proefgebied PPA is vergelijkbaar met een heleboel andere situaties waar provinciale wegen gekoppeld zijn aan autosnelwegen, waar interactie plaatsvindt en waar je in een druk bezet netwerk uitwisseling hebt tussen die netwerken en hoe dit zo optimaal mogelijk te regelen. En aan de andere kant de koppeling provinciaal wegennet – gemeentelijk wegennet waar ook die interactie zit. Basisprincipe PPA, het GNV, de inzichten van wat het gecoördineerd netwerkbreed regelen inhoudt hebben is verkregen met PPA fase 1 en 2. Alle hypothesen die aan het begin opgesteld zijn bij PPA, daar is nu wel zicht op gekregen. Specifiek voor PPA noord heeft de Provincie netwerken geoptimaliseerd en daarna een netwerkregeling los van PPA er overheen laten draaien. De provincie is steeds op zoek naar het optimum, zeker in de situatie waar je een gereguleerd netwerk hebt met meerdere VRI’s achter elkaar met doorgaand verkeer. Uitdaging: hoe haal je het hoogste uit je netwerk met de maximale betrouwbaarheid?
Nr. | Naam | Beschrijving | Beoordeling / volwassenheid / toepasbaarheid |
1.1 | Basis op orde | Vooraleer verkeersmanagement kan worden toegepast, moet de staat van het operationeel, | Areaal is in control met hoge beschikbaarheid, ondanks slechte contracten met aanrijtijden en geen functiehersteltijden. Daar zit een risico in en dat willen ze oplossen door naar prestatieonderhoudscontracten te gaan. |
ADVIN ADVISEURS EN INGENIEURS Pagina | 38
verkeerskundig en technisch beheer (de ‘basis’) van systemen en processen op orde zijn. | Verkeerscentrale nieuw de laatste jaren. Het areaal, aan de buitenkant, is op de VRI’s na ook allemaal nieuw gebouwd de laatste jaren (camera’s, DRIP’s, verbindingen). Het enige ‘oude’ zijn de VRI’s, maar die zijn geüpgradede en zijn technisch maximaal 7 jaar oud. Kleine kanttekening: 2010/2011 hebben ze de keuze gemaakt om niet alles te upgraden, maar om afwegingen te maken. Vb: Bij de N516 stonden nog oude VRI’s die niet op orde waren, maar die zijn voor PPA op orde gemaakt. Het basisniveau van de Provincie ligt aardig hoog. Het zou goed zijn om een toetsmoment tussen knelpunten en GNV te hebben; met wegbeheerders om de tafel en te kijken wat de status van de spullen is. Daar moet wel echt in geïnvesteerd worden. Keuze: upgrade of vervangen? Je kunt je basis op orde hebben, maar uiteindelijk ben je net zo sterk als je zwakste schakel. De lustechniek is vaak de zwakste schakel. Dus zolang men in het VNG-concept afhankelijk is van het meten van voertuigen met een oude techniek, blijft er een risico op de stabiliteit van het totale regelsysteem. Lussen kunnen op zich makkelijk vervangen worden, maar geen enkele beheerder gaat bij iedere afzonderlijke kapotte lus langs om het te repareren. Deze worden opgespaard, zodat het in één keer opgepakt kan worden. Beschikbaarheid is dus ook een stukje kosten/baten en de lussen zijn verreweg de zwakste schakel in het systeem. | ||
1.2 | Meetraai- manager | Verkeersgegevens die via NDW voor verkeersmanagement toepassingen beschikbaar komen, kennen een gemiddelde vertraging (‘latency’) van enkele minuten. Voor RWS snelwegen is door PPA een meetraaimanager ontwikkeld die de data ongeveer 20 seconden na de meetminuut beschikbaar stelt. Deze datalevering is bruikbaar voor andere PPA onderdelen (toepassing | Mee bekend. Beeld ervan: is in noord niet toegepast. Ze hebben het VDS (verkeersdata distributie systeem) en dat is de tegenhanger/alternatief van de meetraaimanager. VDS is een landelijk gestandaardiseerde architectuur en ook vastgesteld en daar is de provincie op aangesloten. Bewuste keuze geweest om geen nieuwe architectuur op te bouwen. VDS is een onderdeel binnen de hele architectuur. Die is gekoppeld met alle systemen binnen de verkeerscentrale van de provincie, waaronder het NMS (die voedt het NMS). En die communiceren op een bepaalde manier met elkaar (daar zijn open standaarden voor). Van de bestaande koppelvlakprotocollen is gebruik gemaakt. Er is geen versnelling in de latency doorgevoerd. Interpretatie van de meetraaimanager: rechtstreeks uit het wegkantsysteem worden de signalen gedistribueerd (in de databus). Dat loopt bij de Provincie nog altijd via het NDW. De |
GNV bijvoorbeeld) maar kan ook worden gebruikt voor de inzet van regelscenario’s als basis voor verkeersvoorspellingen, reistijdadvies en dergelijke. | latency die met het NDW is afgesproken is dat de gegevens niet ouder mogen zijn dan 1 minuut voordat ze weer beschikbaar zijn bij de Provincie. Functionaliteit is herkenbaar; ze willen graag snelle data. Maar hij moet binnen de architectuur passen en ze hebben gekozen voor VDS en afspraken gemaakt met NDW m.b.t. beschikbaar stellen data. Ook kan, omdat je in de architectuur van VDS zit, er andere data zoals V-Lo op aangesloten worden. En juist die data was nodig binnen PPA. Meetraaimanager is natuurlijk gebaseerd op lussen op de rijksweg. De lussen bij de VRI’s zijn anders. Die zijn niet aangesloten op het NDW. Daarom gekozen voor VDS. En daarnaast hebben ze op het traject ook zo goed als geen intensiteitspunten. | ||
1.3 | Kiemen- speurder | De kiemenspeurder is de link tussen netwerkanalyse waarin potentiële knelpunten worden bepaald en de beslissing of een regelaanpak metterdaad moet worden ingezet. De kiemenspeurder geeft real time aan of een knelpunt zal ontstaan en welk regeldoel moet worden bereikt om het knelpunt te voorkomen en/of te verminderen. In PPA is de kiemenspeurder op de snelweg toegepast en is gebleken dat gebruik van lussen als inputdata kan worden ingeruild voor FCD. | Daar heeft de Provincie iets nieuws voor ontwikkeld: de trajectsupervisor (zie 1.9). |
1.4 | Toepassing wachtrij- schatter met extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. In fase 1 PPA zijn daarvoor extra lussen | Er lagen voldoende lussen om het systeem te kunnen voeden. Extra lussen aanleggen was niet nodig. Uit de evaluatie kwam wel naar voren dat de wachtrijschatter met V-Log data onvoldoende is. Met V-Log data kon niet de bufferruimte bepaald worden die beleidsmatig was vastgesteld. De |
aangelegd op de opstelstroken | beheermaatregel wachtrijschatterradar hebben ze toen moeten toepassen (terugvaloptie). | ||
1.5 | Toepassing wachtrij- schatter met radar- detectie | In PPA West en PPA Noord (en bij uitrol elders) wordt radardetectie toegepast om wachtrijen te bepalen. | Mooi product en werkt ook wel goed. Wel gezocht naar wat is nou precies een wachtrij, bij hoeveel km/u? Daar hebben ze een redelijk betrouwbare grens voor gevonden, waardoor de bufferruimtes bepaald konden worden en er geregeld kon worden. De kosten zijn vrij hoog (waarschijnlijk door hoge ontwikkelkosten; dit zal in de toekomst lager kunnen zijn zonder ontwikkelkosten). Bij uitschalen/vergroten zullen de kosten verminderen. Radar zou compleet het detectieveld kunnen vervangen. Bij een proef op de N208 is radar vergeleken met V-Log data. Dit is getest voor een half jaar. Vrij kostbare systemen, resultaat was dat er in principe een alternatief is voor lussen (radar). Er is alleen nog niet beproefd over de gebruiksfase (o.a. beheer). Daarvoor zou de radar er iets van 5 jaar moeten liggen. Bij provinciale wegen is het goed toepasbaar. Bij gemeenten zal het wat lastiger worden bij kortere afstanden en minder ruimte. |
1.6 | Toepassing wachtrij- schatter zonder extra lussen | Om de instroom van verkeer richting knelpunten elders in een netwerk te beperken, wordt bepaald hoe lang wachtrijen op kruispunten zijn. Er is geprobeerd wachtrijen te berekenen zonder extra lussen aan te leggen en gebruik te maken van FCD als (extra) databron.. | FCD wordt veel van verwacht. Met een hoge dekkingsgraad, geen grote latency en de benodigde snelle data die er nodig is zijn er nog wat vraagtekens. Het is de ontwikkeling van de toekomst, maar hoe gaat de grote latency opgelost worden? En kijkt FCD ook voldoende naar afslaand verkeer? (is een openstaande vraag) De informatie is er, maar er is nog niet op doorontwikkeld, ook i.v.m. privacy. |
1.7 | Lokale TDI- VRI koppeling (‘gecoördi- neerde aansluiting’) | Dit is het laagste niveau van gecoördineerd regelen in PPA: één toerit en één verkeerslicht werken samen om de instroom van verkeer van de stad naar de snelweg te beperken als dat nodig en zinvol is. Deze toepassing maakt de | Koppelkabel heeft alleen maar geïnformeerd. Je hebt de informatie nodig. Geprobeerd een verbinding tussen RWS en de verkeerscentrale van de Provincie te maken, maar dit leverde heel veel VTW’s op (dit werkt niet via NMS). Conclusie: Bovenlangs is niet ideaal. Dit kostte zo’n 15:000 EURO om de TDI’s aan te passen en er moest een koppeling tussen de centrales gemaakt worden. Maar het zit gewoon in de V-Log data en de koppeling is er. Vervolgens is het er gewoon ‘uitgeplukt’. |
koppelkabel (die terugslag van wachtrijen op toeritten over kruispunten voorkomt) overbodig. | Technisch kan het, maar er zit een kostencomponent aan vast door eisen van de beheerorganisaties aan de beveiliging en de koppeling. Dit geldt ook voor netwerkregelingen. | ||
1.8 | Netwerk- coördinatie TDI/VRI (‘gecoördi- neerde netwerk- regeling’) | Als meer dan één (lokale) TDI-VRI koppeling worden gecoördineerd neemt de regelruimte toe en kan een groter regeldoel worden beantwoord. In deze netwerkcoördinatie wordt bufferruimte op de diverse plaatsen gelijkelijk verdeeld. | Deze toepassing is primair voor Rijkswaterstaat, vaak in combinatie met gemeentes. Voor de Provincie is deze tool minder interessant. |
1.9 | Traject- supervisor | De trajectsupervisor optimaliseert regelingen van VRI's en TDI's in trajecten (met een richting). | Andere omschrijving is beter: trajectsupervisor verzamelt alle informatie die ingewonnen wordt (wachtrijen en bufferruimtes) en gaat vervolgens daarop acteren. Hij optimaliseert wel, maar de omschrijving kan iets beter. Op basis daarvan doet hij een verzoek naar de green time broker. Trajectsupervisor kijkt met name waar de instroom beperkt kan worden en het NMS is uitgebreid om uitstroom te bevorderen. Op basis van alle beleidsuitgangspunten die er binnen een netwerk zijn, bepalen de trajectsupervisor en NMS hoe belangrijk het is om op een bepaald punt instroom te gaan beperken of uitstroom te gaan bevorderen. Daar wordt weer een gewicht aan gekoppeld. Welke het zwaarst weegt, daar zit een landelijke regelaanpak achter: GGB. (Een aparte GGB voor PPA noord). Dat komt bij de green time broker uit. De green time broker gaat uiteindelijk één verzoek sturen naar de VRI’s. En sturen (naast instroom beperken en uitstroom bevorderen)? Dat zit er in noord niet in. PPA west heeft vooral de instroom beperkt. |
1.10 | Real time netwerk- regeling verkeers- lichten | In fase 1 PPA is voor de trajectcoördinatie van VRI's op S102 gebruik gemaakt van een bestaande netwerkregeling van Vialis. Het is een alternatief voor | Zie 1.9. |
trajectcoördinatie zoals bijvoorbeeld in PPA Noord toegepast (opm.: in regelgebied van PPA Noord is door Provincie NH een vergelijkbaar alternatief beproefd). | |||
1.11 | Green time broker (GTB) | Deze module is in PPA Noord ontwikkeld om conflicterende aanvragen voor aanpassing van regelingen aan VRI automaten af te wikkelen (prioriteiten te stellen). Deze module is nodig in (deel)netwerken waarin de regelingen van VRI's op kruispunten in verschillende richtingen worden gecoördineerd. | Zie 1.9. |
1.12 | Kruispunt- informatie / overstaan algoritme | In PPA Noord is kruispunt informatie (in de databus) opgenomen als input voor regeleenheden. | De kruispuntinformatie module verzamelt allemaal verkeerskundige informatie die aangeboden wordt aan de trajectsupervisor en aan het RMS. Transformeert ruwe data tot verkeerskundige informatie en heeft mappen (vormgeving kruispunten). Dit is specifiek voor de PPA gebouwd (bijv. wachtrijlengtes zitten er in; en dit komt weer uit de V-Log wachtrjischatter of uit de wachtrijschatterradar). Verschillende bronnen die wachtrijen geven (lussen, radar, FCD), dat komt allemaal samen in de kruispuntinformatiemodule. De kruispuntinformatie module is nodig om GNV te kunnen doen en om PPA noord regelconcept uit te kunnen rollen op andere plekken. Bij uitrollen op andere plekken geen kosten voor ontwikkeling en implementatie, wel voor configuratie. Globale schatting (gevoelsmatig) configureren en inregelen is 10.000 EURO per VRI (100 manuren*100 EURO), geen radar aangelegd. Qua inspanning zal het een minder zwaar alternatief dan de i-VRI en de used-case ervan, maar dat komt omdat ze er al meer ervaring mee hebben en er al verder mee zijn. Dit zegt niet dat de i-VRI niet gedaan moet worden. Keuze moet gemaakt worden. PPA werkt goed bij overbelasting van het netwerk, maar niet bij onderbelasting. Situatie PPA noord komt vaker voor in Nederland dan de situatie PPA west. |
1.13 | Gebruik NMS voor | In PPA Noord is anders dan in fase 1 en PPA | Zie 1.9. |
aansturing VRI/TDI | West de aansturing van VRI's en TDI's gedaan vanuit het NMS dat bij de Provincie in productie draait. Daarmee is deze aansturing binnen bereik van bestaande - in verkeerscentrales aanwezige systemen - gebracht. | ||
1.14 | Gebruik databus | In PPA Noord is monitoring informatie verzameld in de bestaande databus die bij de Provincie onder het NMS "hangt". In PPA West en in fase 1 waren monitoring modules en regelmodules nog geïntegreerd in één systeemomgeving. | VDS, zoals besproken bij vraag 1.2. Dit past binnen de architectuur zoals de Provincie wil gaan werken en daarom doen ze het op deze manier. Daarom is het niet project specifiek maar generiek, en alle projecten die worden ontwikkelt kunnen worden gekoppeld aan die databus. De VDS-structuur is door de Xxxxxxxxx zelf bedacht, voordat PPA kwam. Het helpt wel als je een goede datastructuur hebt, want de voorwaarde voor uitrolbaarheid is dat je data op orde is en dat je het kan gebruiken. Dus niet alleen je areaal op orde hebben, maar ook je data. |