Op weg naar de verdere verbetering van IVERA, de 3.0 versie

IVERA presenteert concept 3.0 versie

De Stichting IVERA voorziet de wegbeheerders van een standaard voor de data-uitwisseling tussen automaten van VRI’s en centrales. Deze standaard wordt regelmatig aangepast aan de wensen van wegbeheerders en stelt hen in staat de groeiende ambities op het gebied van verkeersmanagement te realiseren.

In afgelopen maanden heeft IVERA de wensen bij wegbeheerders geïnventariseerd en op grond hiervan een overzicht samengesteld van de nieuwe functionaliteiten in het IVERA protocol. Bovendien heeft IVERA bestaande klantenwensen gerealiseerd die met nieuwe technologische mogelijkheden nu wel gerealiseerd kunnen worden.

Dit overzicht van de nieuwe en verbeterde functionaliteiten wil IVERA graag presenteren in een klantencontactdag. Deze zal plaatsvinden op 25 april 2012, aanvang 15.00 uur in het kantoor van de FME/IVERA, Boerhaavelaan 40 te Zoetermeer. Na afloop wordt een filemijdend buffet geserveerd. Het programma wordt op aanvraag toegezonden. Een e-mail volstaat naar IVERA@fme.nl.

 

 

Geachte wegbeheerders en andere experts,

Onderzoek naar de gewenste functionaliteiten van de nieuwe 3.0 versie, onder wegbeheerders en andere experts over de gewenste vernieuwingen van IVERA.

De Stichting IVERA voorziet de markt van een standaard voor de data uitwisseling tussen VRI’s en centrales. Deze standaard is vastgelegd in het IVERA protocol dat tot stand is gekomen in overleg tussen wegbeheerders en de verkeersindustrie. IVERA bereidt zich nu voor op een nieuwe versie van het protocol dat nog beter in staat moet zijn de wegbeheerders te faciliteren om het verkeer in goede banen te leiden. Voor het up to date houden van het protocol kan de inbreng van de wegbeheerders niet worden gemist.

De inbreng van wegbeheerders en andere experts voor de vigerende versie van het protocol is zeer waardedevol gebleken. De belangrijkste wijzigingen van de huidige 2.10 versie ten opzichte van de 1.3 versie zijn kort samengevat:

IVERA meent dat de rol van de VRI’s en centrales bij het realiseren van de doorstroming verder verbeterd kan worden. De inzet van nieuwe technologie stelt ons in staat de bestaande functies te verbeteren én het protocol uit te breiden met nieuwe functies, die de wegbeheerders beter in staat stelt om de doorstroming te verbeteren, veilig, betrouwbaar en milieuvriendelijk. Te denken valt onder meer aan uitbreiding van het protocol, aan het koppelen van de VRI’s, aan het koppelen van netwerkregelingen, aan de communicatie tussen VRI’s en centrales, aan de communicatie tussen centrales onderling en aan het koppelen met andere systemen.

Tijdpad

Het IVERA bestuur streeft er naar de 3.0 versie van het IVERA protocol eind 2013 op de markt te brengen. Dit is uiteraard mede afhankelijk van het aantal en aard van de gewenste functionaliteiten. Het tijdpad is als volgt:

IVERA stelt wegbeheerders en andere experts graag in de gelegenheid tot en met 31 maart 2011 voorstellen te doen voor de nieuwe 3.0 versie van het IVERA protocol. U kunt uw inbreng aanleveren via www.astrin.nl op weg naar 3.0.

Kort na 31 maart a.s. zal het bestuur van IVERA in goed overleg met de Raad van Toezicht de ontvangen voorstellen gaan inventariseren en met de Technische Werkgroep van IVERA nagaan welke geschikt zijn om omgezet te worden in specificaties. Wij zullen u hierover informeren.

Heeft u vragen of opmerkingen? Neem dan contact op met ons secretariaat.

Tel 079 3531 244
E-mail ivera@fme.nl

Reacties

31-01-2011 om 14:51 W.C. (Willem) Kinzel Ik kon een aantal parameters niet vinden in de objectdefinitie van IVERA-versie 2.10, die er volgens mij wel in horen. Het gaat om parameters die in de nieuwere versies van CCOL zitten, namelijk:
1. signaalplanparameters
2. parameters m.b.t. fluttergedrag

Ad 1. In CCOL zijn sinds versie 5.0 aparte arrays beschikbaar voor (half)starre signaalplansturing. Deze arrays maken ook deel uit van het PARM1-buffer. Het gaat om de volgende arrays:
- TX_max: cyclustijden
- TPL_on: inschakeltijden
- TPL_off: uitschakeltijden
- TXA: vooruitschakelmomenten
- TXB: startgroenmomenten
- TXC: vasthoudmomenten
- TXD: eindegroenmomenten
- TXE: afkapmomenten

Ad 2. In CCOL zijn sinds versie 7.0 aparte arrays beschikbaar voor bewaking op fluttergedrag. Deze arrays maken ook deel uit van het PARM1-buffer. Het gaat om de volgende arrays:
- TFL_max: bewakingstijd fluttergedrag
- CFL_max: maximum waarde fluttergedrag

Ik vind dat bovenstaande arrays ook in het IVERA-protocol thuishoren. Met name bij de signaalplantijden kan er een frequente behoefte tot wijzigen zijn.

Met vriendelijke groet,

ing. W.C. (Willem) Kinzel

Goudappel Coffeng BV

17-02-2011 om 08:13 Bert van der Veen Via ondermeer "Doorstroom" lees ik dat gewerkt gaat worden aan een update van het Ivera protocol. Aangezien ik nog steeds een (gevoelsmatige) binding heb met het Ivera protocol heb ik de behoefte hierop te reageren.

Het ontwikkelen van een nieuwe versie Ivera lijkt me een interessante ontwikkeling die goed aansluit bij de toegenomen wensen ten aanzien van DVM en andere toepassingen. Ik vroeg mij af op welke wijze de gebruikers actief worden betrokken bij de up-date van het protocol. In mijn geheugen is blijven hangen dat het de vorige keer op dit vlak niet helemaal goed is gegaan waardoor bepaalde sleutelgebruikers, op een laat moment in de migratie, niet helemaal tevreden waren met de up-date. Ik vraag mij af of jullie daarom overwegen om een actieve, vanuit de stichting geïnitieerde en uitgevoerde, marktconsultatie te doen. Door een groep sleutelgebruikers zelf actief te benaderen en de overige gebruikers op een interactieve manier er ook bij te betrekken zou je wensen, eisen en (creatieve) suggesties goed boven water kunnen krijgen. Als jullie daar behoefte aan hebben ben ik uiteraard graag bereid hiervoor een voorstel voor uit te werken. Ik hoor het wel.

Met vriendelijke groet,
Advin BV, Marktgroep Ruimte & Mobiliteit


Bert van der Veen
Senior Adviseur

01-03-2011 om 15:06 William Meijer Hierbij een reactie nav. de post van Willem Kinzel. Als verkeerskundige kun je op dit moment de parameters van de genoemde arrays inderdaad niet instellen. Ton v. Grinsven (ontwikkelaar CCOL) heeft echter als reactie gegeven dat de fabrikanten de arrays gewoon op zouden kunnen nemen onder de conventionele parameter lijst daar ze idd technisch uitgewerkt zijn onder de PARM1 buffer.

Ik denk dat we ons als eindgebruikers even af moeten vragen of dat wenselijk is, aangezien de parameterlijst dan wel ongekend lang kan worden. Onze voorkeur zou ernaar uitgaan om een apart object voor 'signaalplan instellingen' in Ivera in te brengen waaronder alle TX arrays komen te vallen.
Voor fluttergedragtijden zou dit ook het fraaiste zijn. Groet, William Meijer / Verkeersregelkundige
Gemeente Rotterdam - dS+V

02-03-2011 om 16:30 wierd janse Kan op dit moment al in een centale een interface worden geboden om datastromen tussen vri's in een LAN instelbaar/flexibel te koppelen in een soort van matrix-interface? Bijvoorbeeld het koppelen van output parameter A uit VRI A aan input parameter X bij VRI B en parameter Y bij VRI C etc. met oneindige veel combinaties. Bestaat dit al? Of staat de ontwikkeling hiervan helemaal los van IVERA en is dit een aangelegenheid van fabrikanten centralesystemen.

16-03-2011 om 07:24 Robert Kooijman Ik zou graag als toevoeging in Ivera willen zien dat storingsmeldingen van rateltikkers worden doorgestuurd naar de centrale. In de backplane van Accrossunits zit een uitgang die aangeeft of er een storing is gedetecteerd binnen een van de units. Het zou mooi zijn wanneer deze uitgang via een ivera-melding ook doorgegeven wordt aan de centrale. Nu zijn we bij storingen in rateltikkers altijd afhankelijk van eigen waarneming, of klachten van burgers.

16-03-2011 om 07:27 Robert Kooijman En nog een wens: het toevoegen van een testsignaal, vanuit een centrale op te zetten, waarna een VRI na twee? minuten gaat uitbellen naar de centrale en een testsignaal teruggeeft.
Hiermee is zowel het in- als uitbellen vanuit de centrale te testen, zonder oneigenlijk gebruik te hoeven maken van meldingen/instellingen die eigenlijk niet daarvoor bedoeld zijn.

Robert Kooijman,
Projectleider Verkeersmanagementsystemen gemeente Rotterdam

31-03-2011 om 09:58 Erik van Holten Graag aandacht voor de volgende zaken:
- een parameter wijzging dient niet alleen opgenomen te worden in parameter logboek maar ook tot een trigger event te leiden zodat wijzgingen (van zowel parameters, schakelaars, klokken ed) binnenkomen op centrale, voor operationeel beheer een must, dit is in de huidige versie niet verplicht;
- standaard naamgeving voor hoe rood-geel-groentijden (inclusief garantie) benaderd kunnen worden;
- nadenken hoe omgaan gaat worden met instellen en actief worden van scenario's;
- nu kun je aangeven welke events tot een directe melding leiden echter dan krijg je wel direct alle logboekmeldingen erbij, mijn voorkeur zou zijn dat je alleen de events gemeld krijgt die je aangeeft;

Erik van Holten, gemeente Tilburg

01-04-2011 om 13:23 Bert Amptmeijer Hierbij het verzoek om aandacht te hebben voor een eenduidige afspraak voor het instellen en uitlezen van verkeerslogging. Uiteraard zijn er mogelijkheden om binnen IVERA eigen commando's te gebruiken. Dit zijn dan echter eigen IVERA commando's die onze klanten als algemene IVERA commando's beschouwen en derhalve ook door alle fabrikanten ondersteund zouden moeten worden. Vooral voor het inwinnen van informatie, wat steeds belangrijker wordt in de toekomst, zijn afspraken, voor V-Log en MV-logging op IVERA niveau, noodzakelijk. Graag in de nieuwe IVERA versie commando's definiëren om dit te bewerkstelligen, Bert Amptmeijer, Product Manager, Vialis Verkeersmobiliteit.

04-04-2011 om 09:11 Hans Diender Bij de provincie Gelderland zien we verkeersregelingen steeds groter en groter worden waardoor de interface afname steeds langer gaat duren. Om deze hoeveelheid werkt te reduceren maak ik al jaren scriptfiles in het begin alleen voor de applicatie kant. Maar sinds kort ook voor de IVERA kant en bij dit laatste daar loop ik tegen problemen aan van standaardisatie. Zie onderstaande voorbeelden.

Voorbeeld: Alle regelingen zijn op de zelfde manier gebouwd dus benamingen zijn overal het zelfde

Opvragen ontruimingstijd

Siemens TOR/05,28
Vialis TOR/5,28 Let op geen tik fout hier wordt de voorloop nul weg gelaten
Peek TOR/FC05,FC28
Kohartog TOR/SG05,SG28


Detector tijden

Siemens tdh/011
Vialis tdh/011
Peek tdh/d011
Kohartog tdh/d_011

Vastgroentijden

Siemens TVG/01
Vialis TVG/01
Peek TVG/FC01
Kohartog TVG/SG01


Schakelaars

Siemens S/WSWG02
Vialis S/WSWG02
Peek S/WSWG02
Kohartog S/S_WSWG02

Tijd elementen

Siemens T/YML01
Vialis T/YML01
Peek T/YML01
Kohartog T/T/YML01

Parameters

Siemens P/TFB
Vialis P/TFB
Peek P/TFB
Kohartog P/E_TFB

Het lijkt mij voor de handliggend dat er voor de benamingen gebruik wordt gemaakt van functionele namen zoals die in de regeling zitten zodat het voor de desbetreffende wegbeheerder overal gelijk is.

Met vriendelijke groet,

Hans Diender
Provincie Gelderland

05-04-2011 om 14:28 Zeger Schavemaker
Het is momenteel niet mogelijk om met een IVERA commando een actuele storingen lijst op te vragen.
VRI.LA wordt namelijk geleegd als een beheercentrale de events uitleest.
Het is wenselijk om op een bepaald moment door de beheerder de actuele (openstaande) storingen in te kunnen zien.

12-04-2011 om 15:13 Lucianne Meerten De kwaliteitscentrale van IT&T wordt veel gebruikt door diverse wegbeheerders. Het zou handig zijn om de instellingen voor het oplaan van MV-files in de automaat vanuit de centrale aan te kunnen sturen en daarna op te kunnen halen. Er zijn momenteel wel onderlinge afspraken tussen VRI-fabrikant met IT&T, maar het zou beter werken als er een standaard voor is.


Reageren

Naam
Uw E-mail
Bedrijf
Bericht
Verstuur
Reageer