DVM-Exchange 2.0 - Open standaard gaat verder

knooppunt-header

Op de afgelopen Intertraffi c is een eerste versie gedemonstreerd van DVM-Exchange, de nieuwe open interface voor  netwerkmanagementsystemen. Met de versie 1.0 van de standaard kunnen netwerkmanagementsystemen van verschillende leveranciers met elkaar ‘praten’. Maar hoe zit het met de zogenaamde verticale communicatie, tussen het netwerkmanagementsysteem en de  onderliggende stuurinstrumenten? DVM-Exchange 2.0 standaardiseert ook díe koppelingen.

Artikel uit NM Magazine #2, 2012 - ook beschikbaar in pdf

Het werkt echt. Op de Intertraffic Amsterdam van 27 tot en met 30 maart dit jaar konden de bezoekers met eigen ogen zien hoe  netwerkmanagementsystemen van verschillende leveranciers op basis van DVM-Exchange commando’s uitwisselen. Erg spectaculair en mediageniek is dat niet – het gaat om protocollen en software – maar het belang voor netwerkmanagement is er niet minder om. Want wil operationeel netwerkmanagement goed van de grond komen, dan moeten de systemen van de samenwerkende wegbeheerders met
elkaar kunnen ‘praten’, ongeacht de leverancier. De standaard DVM-Exchange zorgt daarvoor.

Systeemtopologie

Dat wil zeggen: de gedemonstreerde DVM-Exchange 1.0 is een belangrijke eerste stap naar probleemloze en leveranciersonafhankelijk communicatie tussen verkeerssystemen. Zo is met versie 1.0 horizontale communicatie (systemen op zelfde niveau) tussen  netwerkmanagementsystemen mogelijk, maar is nog niet in verticale communicatie (met onderliggende systemen) voorzien. Uitbreidingen
van de standaard zullen daar uiteindelijk wel voor zorgen.

Om al die koppelingen mogelijk te maken, is het zaak eerst helder te hebben hoe operationeel netwerkmanagement er systeemtechnisch uit zal zien. Er is daarom goed geluisterd naar een aantal ‘netwerkmanagementkoplopers’: wegbeheerders in onder meer de regio’s Zuid-Holland, Zuidoost-Brabant, Amsterdam en Arnhem- Nijmegen. Binnen deze groep is een gezamenlijk beeld ontstaan van een DVM-architectuur. In de fi guur op de bladzijde hiernaast is deze architectuur weergegeven als systeemtopologie, een beschrijving van de benodigde technische systemen.

Boven aan de piramide staat het netwerkmanagementsysteem. Hiermee ontsluit de wegbeheerder de onderliggende DVM-systemen. Er kan een verkeerskundig doel (bijvoorbeeld: instroom verminderen) voor een bepaald gebied worden gedefi nieerd en geactiveerd. Het gekozen doel wordt daarbij vertaald in deelprestaties die geleverd worden door de afzonderlijke DVM-systemen (bijvoorbeeld: doseren bij toeritten). Merk op dat op dit niveau de regionale samenhang van de aanpak wordt gewaarborgd : de verschillende DVM-systemen worden vanuit één netwerkvisie gecoördineerd aangestuurd.

Een trapje lager bevinden zich de DVM-systemen. Deze ontsluiten de stuurinstrumenten en stellen de wegbeheerder in staat de actuele toestand en status van de verschillende stuurinstrumenten te observeren. De wegbeheerder kan de actuele confi guratie van de instrumenten zo aanpassen dat deze invulling geeft aan de in te zetten maatregel (bijvoorbeeld: toeritdoseerinstallatie inschakelen), zodat elk instrument zijn rol in het netwerkbrede verkeersmanagement vervult.

Een belangrijke tussenlaag is het monitorsysteem. Hiermee vergaart de wegbeheerder meetdata en wegverkeersinformatie van diverse systemen, zoals stuurinstrumenten en DVM-systemen. Het monitorsysteem stelt deze informatie ter beschikking aan de DVM-systemen en het netwerkmanagementsysteem. Elk systeem beschikt daarmee over een ‘common operational picture’, een actueel beeld van de situatie op de weg.

Onder aan de piramide bevinden zich de stuurinstrumenten (DRIP’s, toeritdoseerinstallaties, verkeerslichten etc.) – de schakel
met de weggebruikers.

Ideaalbeeld

Het ideaalbeeld is dat wegbeheerders met bovenstaande systemen samenwerken aan het netwerkbreed managen van de verkeerstromen. Dit gebeurt nu al bij bijvoorbeeld evenementen en grootschalige wegwerkzaamheden.

Zo’n samenwerking begint met het vooraf gezamenlijk bedenken en in detail invullen van regelscenario’s. De scenario’s worden vervolgens opgenomen in de netwerkmanagementsystemen van de samenwerkende wegbeheerders. Doet een situatie die is beschreven in een   regelscenario zich voor (‘fi le op locatie X dreigt terug te slaan op afrit stroomopwaarts’) dan kan met één druk op de knop een hele serie aan maatregelen worden ingezet. Op termijn, wanneer de kennis over samenwerken op het juiste niveau is, kunnen vooraf uitgewerkte regelscenario’s worden vervangen door het wederzijds aanvragen van services. Dit kan door wegverkeersleiders of zelfs automatisch door hun netwerkmanagementsystemen. In dat geval ontstaan regelscenario’s spontaan op het moment dat ze nodig zijn.

Voorwaarde

Terug naar de interfaces. Om het ideaalbeeld met de hiervoor beschreven systemen mogelijk en werkbaar te maken, moeten de interfaces of ‘koppelvlakken’ tussen de elementen uit de systeemtopologie aan een aantal eisen voldoen. De wegbeheerders hebben deze eisen vastgelegd in een Interface Requirements Specification (IRS), dat het logische vervolg is op de Operational Concept Description (OCD) van Pakket 20 uit de Mobiliteitsaanpak.

Wanneer we DVM-Exchange 1.0 afzetten tegen de IRS, dan blijkt dat de volgende uitbreidingen noodzakelijk zijn:

  • Naast de ‘horizontale interface’ tussen netwerkmanagementsystemen, is er ook een ‘verticale interface’ nodig tussen een netwerkmanagementsysteem en onderliggende DVM-systemen. Op deze wijze zal het netwerkmanagement zich ook organisch kunnen uitbreiden: andere wegbeheerders of andere deelgebieden kunnen dan makkelijk toegevoegd worden, ongeacht het merk en type systeem dat er in het betreffende gebied gebruikt wordt.
  • Met DVM-Exchange 1.0 is het wederzijds aanvragen van services mogelijk. Maar er moet ook met vooraf gedefinieerde regelscenario’s kunnen worden gewerkt.
  • Verder moet het mogelijk zijn de stand en status van de stuurinstrumenten (DRIP’s, VRI’s, TDI’s etc.) aan elkaar door te geven, zodat wegbeheerders mee kunnen kijken in elkaars beheergebied.

Op initiatief van de wegbeheerders binnen Zuid-Holland, Noord-Holland en Utrecht is dan ook DVM-Exchange 2.0 gedefinieerd: er is een Interface Design Description (IDD) gemaakt dat volgt op het IRS en op DVM-Exchange 1.0. Het IDD is opgesteld door VERDER, BEREIK!, de provincie Noord-Holland, de Gemeente Amsterdam, Vialis, Trinité en Technolution.

De nieuwe versie van DVM-Exchange is zo vormgegeven dat verschillende niveaus van verzoeken tussen de wegbeheerders mogelijk zijn. De logica in de niveaus is dat de vrijheid in het vinden van de juiste oplossing met ieder niveau groter wordt. Ieder niveau kent dan ook een eigen mechanisme waarmee maatregelen worden geactiveerd. Op het laagste, eenvoudigste niveau bijvoorbeeld verzoekt wegbeheerder A aan wegbeheerder B om een vooraf afgesproken set van maatregelen in te zetten. Wegbeheerder B wordt geacht het verzoek direct op de voorgeschreven wijze in te willigen. Maar op de hogere niveaus vraagt A aan B om een bepaald verkeerskundig doel te bewerkstelligen (bijvoorbeeld: minder instroom op ring) en mag B zelf de invulling bepalen. Het hoogste niveau is dan dat B om ‘assistentie’ wordt gevraagd, waarbij wegbeheerder B zelf bepaalt met welk verkeerskundig doel hij in het effectgebied te hulp zal schieten.

Hoe verder?

DVM-Exchange 2.0 is binnenkort afgerond. Connekt is gevraagd als onafhankelijke beheerder, waardoor alle leveranciers en wegbeheerders een gelijkwaardige rol kunnen spelen in deze nieuwe open standaard. Het opgestelde IDD is voor iedereen vrij toegankelijk en op te vragen bij Connekt. De provincie Noord-Holland, de gemeente Amsterdam en Rijkswaterstaat Noord-Holland willen verregaande samenwerking op het gebied van verkeersmanagement. Om eind 2012 operationeel te zijn, laten ze in hun netwerkmanagementsystemen een DVMExchange 2.0-interface implementeren. Hierdoor kunnen ze op operationeel niveau regelscenario’s activeren en wederzijds services aanvragen. Ook in Utrecht wordt dit jaar nog DVM-Exchange 2.0 ingezet in realisatieprojecten. DVM-Exchange 2.0 zal zo de meerwaarde kunnen aantonen van een standaard interface.

 

De auteurs

Paul van Koningsbruggen en Henk den Breejen, beiden Program Manager bij Technolution.

Dit artikel is mede mogelijk gemaakt door:
Rolf Krikke (namens VERDER), Berend Puts en Remco Gilbers (namens BEREIK!), Marcel Fick, Jan Willem Reijtenbagh en Guus Kruijssen (Provincie Noord-Holland), Bert van der Veen en Rien Borhem (Gemeente Amsterdam), Paul de Vries (Rijkswaterstaat, VCNWN), Jos Vranken (TU Delft), Marcel Valé, Joris Feis en Peter Groen (Trinité), Rob Olsthoorn, Roelof Reinsma en Peter Schuringa (Vialis), Erwin Gribnau en William Meijer (Technolution).

Gerelateerde items

Adviessysteem coordineert nat en droog verkeer

Lees verder

Publicatie

Praktische optimalisatie verkeersmanagement

Lees verder

Project

Wat kun je met big data in mobiliteit?

Lees verder

Publicatie

De stille revolutie van de intelligente machine

Lees verder

Publicatie