Prioriteit met Vecom detectie

Prioriteitsaanvragen via Vecomdetectie gaan grotendeels via dezelfde route als de aanvragen via KAR. De TLC zet het Vecombericht zoveel mogelijk op dezelfde posities op de TLC-FI. Er is alleen minder informatie beschikbaar, omdat een Vecombericht uit slechts 8 attributen bestaat.

Vecom bericht op TLC-FI				SRM bericht uit KissRIS
Nr.	Vecom	Beschrijving	TLC-FI	Beschrijving
T1..T6	Vehicle Type	Voertuigsoort (zoals: 1= bus, 2=tram, 3=politie, 4=brandweer, 5=ambulance)	Vehicle Type (zoals: 1= bus, 2=tram, 3=politie, 4=brandweer, 5=ambulance)	Role (eg: 1=publicTransport, 3=specialTransport, 6=emergency) Subrole (eg: 1=bus, 2=tram, 5=emergency, 11=platoon) *
L1..L14	Line Number	Lijnnummer	LineNumber	routeName
D1..D10	Service Number	Service nummer	ServicNumber	tbv match met CAM? **
P1..P2	Punctuality Class	Stiptheidsklasse [NULL=0, 3=vroeg, 2=op tijd, 1=te laat]	Punctuality Class	tbv bepalen priorityImportanceLevel
M3	Ready to Start	Vertrekmelding [1=vertrek]	VehicleStatus [0=noInfo, 3=leaving]	tbv bepalen trigger in flowtack.internal
OL	Overloop	Bovenlus [0=yes, 1=no]	announcementType [= 1 of 2]	tbv bepalen trigger in flowtack.internal
LO1..LO4	Loop Number	Lusnummer [1 t/m 8]	Virtual loop [1 t/m 8, 9 t/m 16, etc]	tbv bepalen trigger in flowtack.internal
PR1..PR4	priorityClass	prioriteitsklasse	priorityClass	priorityClass [0=none, 1=punctuality, 2=regularity, 3=absolute] ***

* op basis van role=emergency en/of subrole=emergency, mag Flowtack ook afkappen

** Service Number wordt op dit moment niet gebruikt. Wanneer hier een nummer wordt gebruikt die overeenkomt met het VehicleID uit het CAM bericht dan wordt het mogelijk om ook deze voertuigen te matchen en te volgen. Dit is nog onzeker.

*** priorityClass wordt ook nog niet gebruikt/gevuld, maar zou indien aanwezig kunnen worden gebruikt om rechtstreek aan een importanceLevel te bepalen.

In- en uitmeldingen

In het Vecom bericht zit geen informatie of iets een (voor)inmelding of uitmelding is. Dit moet worden herleid uit het lusnummer. In de flowtack.internal wordt per sensor opgegeven of het een inmelding

(requestType=request) of uitmelding (requestType=cancel) betreft, of er gekeken moet worden naar de vertrekmelding (considerStartStatus =true/false), welke voertuigtype het betreft, welke signaalgroep het betreft en of, afhankelijk van ‘overloop’ gekeken moet worden naar het opkomen of afvallen van de lus (announchementType =checkin/checkout).

Importance Level

Voor de bepaling van importanceLevel kijken we in eerste instantie naar de puntualityClass uit het Vecom bericht. Aangezien dit geen KAR attribuut is moet er een vertaling plaatsvinden. We kijken daarvoor naar de punctuality die overeenkomt met PunctualityClass uit het KAR bericht. In de flowtack.internal worden de klassen ‘early’ (=3), ‘onTime’ (=2) en ‘late’ (=1), vertaald naar een importanceLevel (bv. 2, 7 en 8 in Deventer). Verschil met KAR is dat de klassen 1 en 3 omgewisseld zijn.

Handig om dit overeen te laten komen met de instellingen in de PriorityBroker.

Voor hulpdiensten wordt default PriorityImportanceLevel 14 gebruikt en wordt bij aanvraag op een enkele signaalgroep, op elke (niet conflicterende) signaalgroep van dezelfde approach absolute prioriteit gezet.

Wanneer de PunctualityClass niet is gevuld (=NULL), kijken we naar Punctuality. Hierin staat de punctualiteit in seconden met een waarde van minimaal -3600 en maximaal +3600 seconden. Deze waarden worden door ons vertaald naar early (-3600 tot 60), onTime (-60 tot + 60) en late (+60 tot +3600), waardoor ze weer op de eerder genoemde manier vertaald kunnen worden naar importanceLevel.

Estimated time of arrival (ETA)

De timing van de prioriteitsverzoek wordt berekend aan de hand van afstand van de inmeldlus ten opzichte van de stopstreep en de geldende maximumsnelheid, zoals vermeld in het ITF. In de Demand module kan hier nog een aanpassing op plaatsvinden op basis van de actuele wachtrij. De ETA wordt dan verlaagd met de tijd die nodig is om het aanwezige verkeer af te laten rijden.