iVRI specificaties

Deze tekst is gepubliceerd op 30-06-21

15 Priority services

Datum besluit SC 08-11-2022
D3047-15 / Version 1.1.1

Disclaimer (NL):
Bij het gebruik en toepassen van de Landelijke iVRI standaarden® is en blijft de gebruiker, te weten de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, zelf aansprakelijk voor de mogelijke risico’s die ontstaan of kunnen ontstaan uit het aanbieden of laten aanbieden van (combinaties van) diensten en producten die conform deze standaarden werken in de eigen organisatie of elders in de keten waarvoor de wegbeheerder verantwoordelijk is. Dit geldt in het bijzonder ten aanzien van het verzamelen, opslaan en delen van gegevens en meer specifiek indien daar waar al dan niet direct of indirect herleidbare persoonsgegevens worden verwerkt op grond van de AVG. Gebruikers zijn zelf verantwoordelijk om bij het gebruik van de standaarden telkens na te gaan of gebruik van standaarden, dan wel de combinatie van data vanuit de standaarden in de basis voldoet aan de wet- en regelgeving, in het bijzonder de AVG. Het gebruik conform de standaarden kan het risico op aansprakelijkheid van de wegbeheerder verkleinen, maar niet altijd wegnemen of geheel uitsluiten. Dit is mede afhankelijk van de wijze waarop de wegbeheerder zelf in haar eigen organisatie of bij gebruik van opdrachtnemers in de keten de data verwerkt en gebruikt. Het is dan ook een dringend advies zowel voorafgaand aan de implementatie en ingebruikname door de gebruiker van de standaarden als periodiek een risico-analyse (zoals Data Protection Impact Assessment (DPIA)) en controle van de keten op het gebruik van de standaarden en bijkomende individuele risico’s bij de wegbeheerder en haar opdrachtnemers uit te laten voeren. Het doel van dergelijke analyses en controles is dat mogelijke risico’s die onbedoeld kunnen optreden op voorhand geïdentificeerd kunnen worden, zodat de wegbeheerder zelf de nodige beheersmaatregelen kan treffen om (alsnog) aan de wettelijke voorschriften te kunnen voldoen. CROW en de opstellers van de standaarden hebben deze documenten met de grootst mogelijke zorg en met aandacht opgesteld, maar kunnen geen aansprakelijkheid aanvaarden voor een mogelijke overtreding van wet- en regelgeving door de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, door te verwijzen naar de standaarden als oorzaak van een mogelijke overtreding van de AVG of andere wettelijke voorschriften. CROW en de opstellers van de standaarden wijzen derhalve een aansprakelijkheid door gebruikers ten aanzien van het gebruik van de standaarden Landelijke iVRI standaarden® van de hand.

Disclaimer (EN):
When using and applying the Landelijke iVRI standaarden® the end user, being the road authority or its principal, remains solely responsible for the possible risks that emerge or can emerge from the provision of services and products that operate by these standards, either within the own organisation or elsewhere in the chain of the road authority’s responsibility. This especially applies to the activities where data is gathered, stored and shared, and more specifically in cases where, be it directly or by inference, private data of individuals are processed, based on the GDPR and/or its national implementation. The user of these standards are themselves responsible for ascertaining that either the use of these standards, or the combination of data that is processed from applying these standards, are legal, especially in terms of the GDPR and/or its national implementation. The use of these standards can reduce the risks for liability of road users, but they can not eliminate these risks; the beforementioned risks of violating privacy legislation are mainly dependent on the way in wicht the road authority uses and processes the data within the own organisation and in relation to contractors within the chain of responsibility. It is urgently advised that, not alone when preparing a project, but also when implementing and operating a service or product, the road authority performs a periodic risk analysis (like a Data Protection Impact Assessment (DPIA)) and a check on the whole chain of information in terms of compliance to standards and additional individual risks on behalf of the road authority and its contractors. The purpose of these analyses and checks is to identify the possible risks beforehand, in order to take preventive and controlling measures, so that the road authority (eventually) is compliant to the legal framework that is applicable. CROW and the authors of these standards have created this document with the utmost care, but will not accept liability for a possible violation of any legislation by the road authority or its contractors by referring to these standards as the root cause of a possible violation of the GDPR, its national implementation or any other legal prescription. CROW and the authors of the Landelijke iVRI standaarden® therefore explicitly waive all responsibility for the use of these standards.

Voorwoord

Met de landelijke publiek private standaarden voor iVRI’s uit 2016 is de afgelopen jaren veel ervaring opgedaan. Enkele van deze standaarden waren al op onderdelen aangescherpt. Eind 2020 is besloten tot een integrale zogenaamde consolidatieslag op al deze standaarden. Met als doel om o.b.v. de opgedane ervaringen en inzichten de ontwikkeling, configuratie, werking en het beheer van (diensten in) de gehele dataketen eenvoudiger en betrouwbaarder te maken. Dit betreft niet alleen standaarden voor iVRI’s, maar ook landelijke afspraken en standaarden over data die cloud service providers aanleveren aan en afnemen van iVRI’s.

Grotere aanpassingen, zoals iVRI security, herziening van beheerinterfaces, ketenbeheer en functionele doorontwikkelingen van diensten (use cases), zijn buiten deze consolidatieslag gehouden en zullen nadien stapsgewijs moeten worden opgepakt. In die zin zal doorontwikkeling van (diensten in) de dataketen doorgaan.

Het voorliggende CROW document is vastgesteld door de landelijke publiek private Strategic Committee en omvat een van de landelijke publiek private iVRI CROW standaarden die is geactualiseerd als onderdeel van de Consolidatie. Aan de actualisatie hebben deskundigen van bedrijven, zowel leveranciers van hardware en software voor iVRI’s als cloud service providers, en overheden actieve bijdragen geleverd. Zoals altijd het geval is bij landelijke standaardisatie, was het niet mogelijk om met de resulterende specificaties en standaarden volledig recht te doen aan alle soms uiteenlopende visies, meningen en standpunten. Door het gevolgde landelijke publieke private proces via de Change Advisory Board en de Strategic Committee zijn al deze visies, meningen en standpunten wel gehoord en gewogen.

De volgende bedrijven hebben actieve bijdragen geleverd aan de iVRI CROW standaarden (in alfabetische volgorde):

Be-Mobile
Dynniq
KPN
Monotch
RHDHV
Siemens Nederland
Siemens België
Swarco
Sweco
Van Grinsven software
Vialis

Vanuit alle landsdelen hebben overheden actieve bijdragen geleverd aan de landelijke iVRI CROW standaarden, te weten de landsdelen Noord, Noordwest, Oost, Zuid en Zuidwest. Daarnaast hebben het Vlaamse Agentschap Wegen en Verkeer, het ministerie van Infrastructuur en Milieu en Rijkswaterstaat actieve bijdragen geleverd.

Dank gaat uit naar allen voor deze bijdragen.

Verdere gewenste aanpassingen en doorontwikkeling van de nu voorliggende standaarden zal plaatsvinden via het daartoe ingerichte landelijke proces via Change Advisory Board en Strategic Committee.

Contents

1 – Introduction
1.1 – Overview
1.2 – Goal of this document

2 – General Priority Services
2.1 – Use Cases
2.2 – Actors
2.3 – Principles and Conditions
2.4 – Priority Broker Configurator
2.5 – ETA calculation
2.6 – SSM status
2.7 – SRM role and subrole
2.7.1 – Role
2.7.2 – Subrole
2.8 – StationType
2.9 – Public Transport
2.9.1 – SRM
2.9.2 – CAM:PtActivation

3 – Priority Use Case
3.1 – Actors
3.2 – Pre-Conditions
3.3 – Trigger
3.4 – Normal Flow
3.4.1 – Feedback
3.4.2 – Update
3.4.3 – ETA change
3.4.4 – Change in vehicle features
3.4.5 – Passing the stop line
3.5 – Post-Conditions
3.6 – Exception flows
3.6.1 – Flow: PRG_end_priorityrequest
3.6.2 – Flow: iTLC_reject
3.6.3 – Flow: iTLC_reject_max_presence
3.6.4 – Flow: iTLC_reject_reservice_locked
3.6.5 – Flow: iTLC_ETA_out_of_range
3.7 – Exceptions
3.7.1 – Exception #1 (Rejected by iTLC invalid priority request)
3.7.2 – Exception #2 (Reject reservice locked - by iTLC)
3.7.3 – Exception #3 (Reject by iTLC)
3.7.4 – Exception #4 (SRM Update timeout)
3.7.5 – Exception #5 (ETA increase)
3.7.6 – Exception #6 (Reject by iTLC during priority handling)
3.7.7 – Exception #7 (Processing timeout by iTLC)
3.7.8 – Exception #8 (Granted timeout)
3.7.9 – Exception #9 (Vehicle characteristics)
3.7.10 – Exception #10 (Invalid ETA)
3.7.11 – Exception #11 (Vehicle characteristics have changed)
3.7.12 – Exception #12 (Change in Connection and/or approach at the same intersection)
3.7.13 – Exception #13 (Changed route, not involving the intersection anymore)
3.7.14 – Exception #14 (No cancellation received by the iTLC)
3.7.15 – Exception #15 (SSM not received on time)

4 – Use case: Priority for Emergency Vehicles (A1-drive, smooth transport)
4.1 – Goal
4.2 – Actors
4.3 – Pre-Conditions
4.4 – Trigger
4.5 – Normal Flow
4.6 – Post-Conditions
4.7 – Exceptions
4.7.1 – Exception #20 (Unknown Connection)

5 – Use Case: Public Transport Priority
5.1 – Goal
5.2 – Actors
5.3 – Pre-Conditions
5.4 – Trigger
5.5 – Normal Flow
5.6 – Post-Conditions
5.7 – Exceptions
5.7.1 – Exception #21 (Unknown Connection)

6 – Use Case: Priority for Trucks
6.1 – Goal
6.2 – Actors
6.3 – Pre-Conditions
6.4 – Trigger
6.5 – Normal Flow
6.6 – Post-Conditions
6.7 – Exceptions
6.7.1 – Exception #21 (Unknown Connection)

7 – Appendix A: SSM status diagram
7.1 – Normal flow
7.2 – Exceptions

8 – Appendix B: SSM status sequences

9 – Appendix C: Background information

1 Introduction

1.1 Overview

Until the end of 2020, the Dutch ministry of infrastructure (I&W), local authorities and commercial companies are investing 90 million Euro in the Partnership Talking Traffic. The partnership of the traffic, telecommunications, internet, and automotive industry has been formed to develop and deploy innovative traffic solutions: intelligent traffic light controllers (iTLCs), cloud services and improved information services.

An important use of these systems is to provide priority to specific target groups. For example a traffic controller (iTLC) can provide a bit more green time to heavy trucks, reducing the need to brake and accelerate. This reduces emissions and improves the traffic flow. Also other target groups like public transport and emergency services can be given priority, dependent on their location, route and the policy of the local authorities. By aligning traffic flows and individual road users the overall traffic flow, safety and air quality are improved.

1.2 Goal of this document

This document describes how, in the Talking Traffic environment, priority services must be handled by intelligent traffic controllers (iTLCs) for the target groups public transport, emergency services and logistics.

In chapter 2 the generic principles of the priority services are described. Chapter 3 captures the generic priority use case, including exceptions. The chapter 4, 5 and 6 describe use cases for the specific target groups.

The use cases refer to the specific Dutch standards to specify the data elements that have to be exchanged. See https://www.crow.nl/thema-s/verkeersmanagement/landelijke-ivri-standaarden.

2 General Priority Services

2.1 Use Cases

The next chapters contain various priority use cases for specific target groups. A use case defines the interaction between a number of actors to provide priority for an oncoming vehicle. Each use case description contains the following sections:

Goal: a short description of the aim of the use case.
Actors: the actors active in this use case. An actor describes the role being played by a person or a system.
Pre-condition: the requirements that have to be met before the use case can start.
Trigger: the event that starts the use case.
Normal flow: the flow of events under normal conditions (happy flow).
Post-condition: the state reached after the use case ends.

2.2 Actors

iTLC: An iTLC consists of the following three components:

ITS-application: contains the traffic control algorithm and supports among others the use cases informing, optimising and/or prioritising.
The Traffic Light Controller (TLC) that controls and safeguards the traffic lights.
The Roadside ITS Station (RIS) that provides the connection to the cloud. It also provides map matching of vehicles, bicycles and pedestrians on a digital map.

RO: The Road Operator uses policy rules to define the way traffic is controlled at an intersection. The RO also makes sure the rules for priority services are captured in the PBC.

PBC: The PBC (Priority Broker Configurator) is a central place where road operators (ROs) can digitally capture and maintain the criteria for vehicles that want to get priority at intersections. The rules defined in the PBC are used by the PRG to determine if a priority request is allowed to be serviced.

OBU: The OBU (On Board Unit) is a vehicle system that allows real time communication. It sends real time location information (GPS coordinates, heading and speed) to the PRG. An OBU can have a Human Machine Interface (HMI) to interact with the driver (the HMI is out of scope of this document).

PRG: The PRG (Priority Request Generator) is the function that sends priority requests to an iTLC. To be able to do this the PRG receives real time information from the OBU. Optionally, the PRG can use information from other sources. The PRG reports the status of the priority service to the OBU. Based on the rules from the PBC the PRG verifies if a vehicle is eligible to get priority at an intersection.

EB: The EB (External Blocking) is the collection of external input that can impact the priority service. For example information on an open bridge, tunnel closure or a closed railway crossing.

[ link ]

Figure 1. The relations between actors

2.3 Principles and Conditions

The following principles and conditions have been determined for the handling of priority for public transport, emergency services and logistics:

The conditions that determine if a vehicle can get priority (for example blue light and siren for emergency vehicles, schedule deviations for public transport) are captured in the rules of the PBC.
Privacy by design.
The use cases are implemented in the Talking Traffic eco system. The communication between the Cloud and the road side systems runs through the TLEX and is based on ETSI messages (MAP, SPAT, CAM and SRM) according to the Dutch Profile.
The HMI (in the vehicle) is outside the scope of the use cases.
The PRG can request priority when the vehicle is at a large distance from the intersection (outside the range of the MAP).
It is possible that there will be controlled and uncontrolled intersections, roundabouts etc. between the vehicle and the intersection for which priority is requested by the PRG.
De PRG may request priority if the vehicle can reach the intersection in less than [5] minutes (MaxETA).
When an iTLC answers a priority request with granted, the request cannot be cancelled by the iTLC anymore. The vehicle priority is guaranteed.
The way an iTLC controls the traffic, and for examples reduces queues, is outside the scope of this document.
Possible future functionality will be supported where possible:
All actors between the vehicle and the iTLC must be able to provide diagnostic information on the processing of priority requests.
CAM messages for a vehicle must be provided to the iTLC once per second as long as the vehicle is on the MAP. This is compliant with Talking Traffic. Outside the MAP CAM delivery is optional.

2.4 Priority Broker Configurator

The RequestImportanceLevels in the PBC uses the following principles:

The iTLC uses the RequestImportanceLevel to determine the weight of a priority request. A higher number in the RequestImportanceLevel has a higher weight.
The RequestImportanceLevels 1 up to and including 10 are used for conditional priority.
The RequestImportanceLevels 11 up to and including 14 are used for absolute priority.
The RequestImportanceLevels 0 and 15 are not used.

2.5 ETA calculation

The calculation of the Estimated Time of Arrival is based on the following principles:

The ETA is calculated from the current vehicle position until the stop line in the ITF.

The ETA is the addition of two travel times:

-	ETA = Travel time to MAP area + Travel time on MAP area

-	Travel time to MAP area = determined by C2

-	Travel time on MAP area = Distance to the stop line / global SpeedLimit (i.e. assuming free flow traffic and excluding any traffic control induced delay)

-	In both cases with consideration of additional expected dwell time at stops (e.g. the duration of time the transit vehicle is stopped for serving passengers or is on hold until the scheduled departure time)

2.6 SSM status

The unambiguous SSM status values, as used in this document, are defined in the table below.

ETSI	Dutch profile D3046-4 SSM data	According to this document
Unknown(0), Unknown state	unknown (0) not used
requested (1), This prioritization request was detected by the traffic controller	requested (1) e.g. request was detected, awaiting map matching data	Acknowledge that the request has been received by the ITS application. The contents of the request have not yet been validated by the ITS application. The request is not used by the ITS application to determine the traffic control.
processing (2), Checking request (request is in queue, other requests are prior)	processing (2) e.g. request is technically approved, request is in queue.	The request has been validated by the ITS application, and is being processed. The request is used by the ITS application, and if necessary the traffic control is adapted accordingly. If the iTLC produces SPAT timing information the request has been incorporated.
watchOtherTraffic (3), Cannot give full permission, therefore watch for other traffic Note that other requests may be present	watchOtherTraffic (3) for emergency vehicles this value implies all red priority.	A variant of the granted status, only used for emergency vehicles. All traffic signals are set to red (or will be set to red soon) allowing the emergency vehicle to pass the intersection while the other traffic is waiting for a red light. It is allowed to provide the watchOtherTraffic state to multiple emergency vehicles, from conflicting directions, that request priority at the same time.
granted (4), Intervention was successful and now prioritization is active	granted (4) prioritization is active, timing data to be derived from SPAT.	The ITS application will keep the traffic light green until the vehicle has passed the intersection. If the iTLC produces SPAT timing information the request has been incorporated. Specific for emergency vehicles (A1): the granted status can already been given at a moment that not all traffic lights are green and the intersection is still being cleared.
rejected (5), The prioritization or pre-emption request was rejected by the traffic controller	rejected (5) request was rejected	The priority request is rejected.
maxPresence (6), The Request has exceeded maxPresence time. Used when the controller has determined that the requester should then back off and request an alternative.	maxPresence (6) -- maximum presence time exceeded	The priority request is rejected with reason maxPresence. This status can only appear after: a timeout exception in the granted status, a timeout exception in the processing status.
reserviceLocked (7), Prior conditions have resulted in a reservice locked event: the controller requires the passage of time before another similar request will be accepted	reserviceLocked (7) -- maximum number of requests for manoeuvre within time frame exceeded	The priority request is rejected with reason reserviceLocked. In general this means that priority cannot be provided at the moment.

Table 1 SSM state

2.7 SRM role and subrole

The SRM fields role and subrole determine the requested use case.

2.7.1 Role

The role [BasicVehicleRole] is defined conform the CAM definition, ETSI TS 102 894-2 (CDD):

default(0): default vehicle role as indicated by the vehicle type (DE_StationType),
publicTransport(1): vehicle is used to operate public transport service,
specialTransport(2): vehicle is used for special transport purpose, e.g. oversized trucks,
dangerousGoods(3): vehicle is used for dangerous goods transportation,
roadWork(4): vehicle is used to realize roadwork or road maintenance mission,
rescue(5): vehicle is used for rescue purpose in case of an accident, e.g. as a towing service,
emergency(6): vehicle is used for emergency mission, e.g. ambulance, fire brigade,
safetyCar(7): vehicle is used for public safety, e.g. patrol,
agriculture(8): vehicle is used for agriculture, e.g. farm tractor
commercial(9): vehicle is used for transportation of commercial goods
military(10): vehicle is used for military purpose
roadOperator(11): vehicle is used in road operator missions
taxi(12): vehicle is used to provide an authorized taxi service
reserved(13-15)

Note: this definition is the same as the VehicleRole definition in the IDD RIS-FI (CROW D3047-4)

2.7.2 Subrole

The subrole [RequestSubRole] uses the following definition:

requestSubRoleUnKnown (0),
requestSubRole1 (1), -- bus
requestSubRole2 (2), -- tram
requestSubRole3 (3), -- metro
requestSubRole4 (4), -- train
requestSubRole5 (5), -- emergency (with or without blue light and/or siren)
requestSubRole6 (6), -- smooth transport
requestSubRole7 (7), -- timetable drive
requestSubRole8 (8), -- regularity drive
requestSubRole9 (9), -- high quality public transport ( HOV)
requestSubRole10 (10), -- outside service public transport vehicle
requestSubRole11 (11), -- platoon
requestSubRole12 (12), -- EcoDriving
requestSubRole13 (13),
requestSubRole14 (14),
requestSubRoleReserved (15)

Remarks:

Subrole 11 has been added to indicate a platoon or convoy of vehicles that must pass the green light together.
Subrole 12 has been added to support EcoDriving trucks.
The definition of VehicleSubRole in the IDD RIS-FI (CROW D3047-4) must be changed to include these new definitions.

2.8 StationType

The iTLC cannot determine the use case to use when the SRM message contains a role value default (0). Consequently priority will be rejected unless the iTLC has received a CAM message prior to the SRM message. In that case the iTLC will use the StationType (from the CAM message) to select the use case.

Note: the above does not apply to the use cases described in this document. As no roles have been defined for, among others, bicycles and pedestrians, the StationType can be used to select future priority use cases.

2.9 Public Transport

2.9.1 SRM

It is mandatory to set the line number of a public transport vehicle in the routeName [Descriptive-Name] field.

The line number must be identical to the line number in the PtActivation data (CAM).

NOTE: due to GDPR considerations the line number can not be provided and need be set to 0 (zero) .

2.9.2 CAM:PtActivation

For public transport vehicles that request priority the following requirements for the PtActivation data in the CAM message must be met:

The line number is mandatory.
The other fields are optional, if the value is unknown the value 0 must be used.
The Vehicle ID must only be used if also the Company number is provided. The combination of Vehicle ID and Company number must be unique.

Octet #	Field name	Value
0,1	Line nr PT	The line number of the vehicle (1..9999)
2,3	Vehicle ID	The vehicle ID (1 9999)
4,5	Block nr	Vehicle Service number/Block number (1...)
6,7	Journey nr	Journey number (1...)
8,9	Support journey nr
10	Company nr	The number of the transport company
11,12	Occupancy	The number of passengers in the vehicle

NOTE: due to GDPR considerations the line number and the other privacy related fields , like vehicle id etc. , cannot be provided and need to be set to 0 (zero) .

3 Priority Use Case

3.1 Actors

iTLC, RO, PBC, OBU, PRG, EB

3.2 Pre-Conditions

The intersection is controlled by an iTLC that supports the Priority Use Case.
The OBU of the vehicle provides the required data.
The PBC has been configured for the intersection according to the policy for priority vehicles of the RO.
The full chain of the services, including the PRG, is operational.
All system clocks of the actors are synchronised.

3.3 Trigger

The PRG determines, based the current vehicle data from the OBU, that the vehicle will pass the intersection within [5] minutes.

3.4 Normal Flow

The PRG determines which connection of the intersection the vehicle will take.
The PRG validates the priority request with the rules stored in the PBC and determines the priority level.
The PRG validates that the estimated time of arrival (ETA) of the vehicle is within [5] minutes.
De PRG sends a priority request (SRM priorityRequest) to the iTLC.
The iTLC acknowledges the receipt of the SRM message within [1] second and sends a response (SSM Requested, Processing, Granted/WatchOtherTraffic) to the PRG.
The PRG forwards the status to the OBU.

3.4.1 Feedback

Periodically the iTLC determines the actual status (requested, processing, granted, watchOtherTraffic) of the priority request.
On a status change the iTLC will inform the PRG (SSM - requested, processing, granted, watchOtherTraffic).
The PRG forwards the current status to the OBU.
The iTLC will inform the PRG on changes in the SPAT timing information.
The PRG forwards the timing information to the OBU.
For directions that will encounter additional waiting time the iTLC will send out SPAT messages with reason for waiting information.

3.4.2 Update

The PRG determines that the last priority request message (SRM priorityRequest, priorityRequestUpdate) has been sent more than [10] seconds ago.
The PRG sends a priority update message (SRM priorityRequestUpdate) with the current ETA to the iTLC.
The iTLC replies to the PRG with an SSM message containing the current status.
The PRG forwards the current status to the OBU.

3.4.3 ETA change

The PRG periodically calculates the ETA, and determines that the ETA differs from the previously sent one.
The PRG sends a priority update (SRM priorityRequestUpdate) with the current ETA to the iTLC when the difference between the actual and previous ETA is more than 10% of the remaining travel time (with a minimum of 3 seconds).
The iTLC replies to the PRG with an SSM message containing the current status.
The PRG forwards the current status to the OBU.

3.4.4 Change in vehicle features

The PRG determines that the vehicle characteristics have changed.
The PRG validates the priority request based on the PBC rules and determines the priority level.
The PRG sends a priority update (SRM priorityRequestUpdate) to the iTLC.
The iTLC replies to the PRG with an SSM message containing the current status.
The PRG forwards the current status to the OBU.

3.4.5 Passing the stop line

The PRG determines that the vehicle has passed the stop line and terminates the priority request (SRM - priorityCancellation) with the iTLC.
The iTLC removes the priority request and adapts the traffic control is necessary.
The PRG forwards the current status to the OBU.

3.5 Post-Conditions

Normal traffic control is active in the iTLC.
The PRG will not request priority again as long as the vehicle continues on the planned route over the intersection, not yet passing the intersection and the trigger condition being true.

3.6 Exception flows

For the handling of exceptions the following exception flows are used:

3.6.1 Flow: PRG_end_priorityrequest

The PRG send a cancellation message (SRM priorityCancellation) to the iTLC.
The PRG forwards the current status (cancellation) to the OBU.
The iTLC removes the priority request.
The iTLC adapts, if necessary, the traffic control (normal control).

3.6.2 Flow: iTLC_reject

The iTLC sends a rejection message (SSM - rejected) to the PRG.
The PRG send a cancellation message (SRM cancellation) to the iTLC.
The iTLC removes the priority request.
The PRG forwards the current status (rejected) to the OBU.

3.6.3 Flow: iTLC_reject_max_presence

The iTLC sends a rejection message (SSM - maxPresence) to the PRG.
The PRG send a cancellation message (SRM cancellation) to the iTLC.
The iTLC removes the priority request.
The PRG forwards the current status (maxPresence) to the OBU.

3.6.4 Flow: iTLC_reject_reservice_locked

The iTLC sends a rejection message (SSM - reserviceLocked) to the PRG.
The PRG send a cancellation message (SRM cancellation) to the iTLC.
The iTLC removes the priority request.

The PRG forwards the current status (reserviceLocked) to the OBU.

3.6.5 Flow: iTLC_ETA_out_of_range

The iTLC sends a rejection message (SSM - rejected) to the PRG.
The iTLC adapts the traffic control if necessary.
The PRG send a cancellation message (SRM cancellation) to the iTLC.
The iTLC removes the priority request.
The PRG forwards the current status (rejected) to the OBU.

3.7 Exceptions

3.7.1 Exception #1 (Rejected by iTLC invalid priority request)

The iTLC cannot fulfil a priority request because it is invalid. Possible causes among others: missing ETA, ETA in the past or more than [5] minutes in the future, missing priority class.

Handling:

The priority handling is not activated.
Flow: iTLC_reject

3.7.2 Exception #2 (Reject reservice locked - by iTLC)

The iTLC cannot fulfil a priority request because too many priority requests have been allowed previously. Providing priority again would have too much impact on the other traffic.

Handling:

The priority handling is not activated.
Flow: iTLC_reject_reservice_locked

3.7.3 Exception #3 (Reject by iTLC)

The iTLC cannot fulfil a priority request. Reasons could be that EB is active or that another priority request (with a higher priority) has already been planned.

Handling:

The priority handling is not activated.
Flow: iTLC_reject

3.7.4 Exception #4 (SRM Update timeout)

The iTLC did not receive an update (SRM) for a vehicle for more than [10 + 5] seconds.

Handling:

The iTLC ends the priority service.
Flow: iTLC_reject

3.7.5 Exception #5 (ETA increase)

The iTLC receives and update with an ETA value later than the previous value, as a result the priority request cannot be handled anymore.

Handling:

The iTLC sends a message (SSM - requested) to the PRG.
The iTLC adapts the traffic control if necessary.

3.7.6 Exception #6 (Reject by iTLC during priority handling)

The iTLC is servicing a priority request (SSM requested has been sent) but concludes that the request cannot be handled anymore.

Handling:

The iTLC ends the priority service.
Flow: iTLC_reject

3.7.7 Exception #7 (Processing timeout by iTLC)

The iTLC concludes that a priority request has been in the state processing for too long [MaxProcessing].

Handling:

The priority handling is not activated.
Flow: iTLC_reject_max_presence.

3.7.8 Exception #8 (Granted timeout)

The iTLC has locked the traffic control for a vehicle for too long, longer than the maximum time defined by the road operator (RO).

Handling:

The iTLC ends the priority service.
Flow: iTLC_reject_max_presence.

3.7.9 Exception #9 (Vehicle characteristics)

The PRG determines (based on the PBC rules) that a vehicle is not eligible to get priority.

Handling:

The PRG will not request priority at this specific intersection.
The PRG indicates to the OUB that the vehicle is not eligible to get priority. The reason why is passed to the OBU by the PRG.

3.7.10 Exception #10 (Invalid ETA)

The PRG determines during the re-calculation of the ETA that the ETA is larger than MaxETA.

Handling:

Flow: PRG_end_priorityrequest

3.7.11 Exception #11 (Vehicle characteristics have changed)

The PRG determines (while validating a priority request update) that, based on the PBC rules, the vehicle no longer is eligible to get priority.

Handling:

Flow: PRG_end_priorityrequest

3.7.12 Exception #12 (Change in Connection and/or approach at the same intersection)

The PRG determines that the vehicle will take a different connection and/or approach at the intersection.

Handling:

Flow: PRG_end_priorityrequest
The PRG initiates a new priority request (normal flow).

3.7.13 Exception #13 (Changed route, not involving the intersection anymore)

The PRG determines that the vehicle will no longer pass the intersection.

Handling:

Flow: PRG_end_priorityrequest

3.7.14 Exception #14 (No cancellation received by the iTLC)

The iTLC expects a cancellation, but did not receive it after [60] seconds.

Handling:

The iTLC removes the priority request.

3.7.15 Exception #15 (SSM not received on time)

The PRG did not, within [1] second, receive an SSM after sending an SRM.

Handling:

The PRG logs the error
The PRG sends an SRM update
After [3] successive errors, the PRG the Flow: PRG_end_priorityrequest

4 Use case: Priority for Emergency Vehicles (A1-drive, smooth transport)

4.1 Goal

The use case for Emergency Vehicles (A1-drive) aims to provide a safe and quick passage over a controlled intersection. In case of smooth transport the aim is to provide a safe passage avoiding decelerations and accelerations.

A1- urgency (A1-drive )

An emergency drive ordered by a central operator in case of an acute threat to the vital functions of a patient, or in case of a danger that can only be excluded by local assessment of an ambulance unit. The drive is ordered as soon as possible and the ambulance unit should be at spot as quickly and safely as possible.

The ambulance uses optical and audible signals. For an emergency vehicle that is performing an A1-drive altered traffic rules apply (allowing to violate the maximum speed limit, etc.).

https://www.ifv.nl/kennisplein/Documents/20160101-VVN-AmbulancezorgNL-Brancherichtlijn-optische-en-geluidssignalen-SMH.pdf

Smooth transport

During smooth transport the driver complies with the normal traffic rules, the vehicle must pass a traffic light during the green phase.

4.2 Actors

iTLC, RO, PBC, OBU, PRG, EB

4.3 Pre-Conditions

The intersection is controlled by an iTLC that supports the use case Emergency Vehile Priority.
The PBC has been, according to the policy of the RO, configured to allow A1-drives or smooth transport for emergency vehicles.

4.4 Trigger

The PRG determines, based on current vehicle data from the OBU, that the emergency vehicle is executing an A1-drive or smooth transport drive and will pass the intersection within [5] minutes.

4.5 Normal Flow

The iTLC determines, based on the role= emergency (6) and subrole= requestSubRole5 (5), -- emergency, that A1-drive priority has been requested.
The iTLC determines, based on the role= emergency (6) and subrole= requestSubRole6 (6), -- smooth transport , that smooth transport priority has been requested.

4.6 Post-Conditions

4.7 Exceptions

4.7.1 Exception #20 (Unknown Connection)

The PRG is not able to determine which connection the vehicle will take across the intersection.

Handling:

The PRG uses a priority request based on an approach.
The PRG finds all signal groups of the approach in the PBC, and uses the highest priority class found.

5 Use Case: Public Transport Priority

5.1 Goal

The Public Transport Priority use case aims to let public transport vehicles to pass a controlled intersection faster, given that certain criteria are met (for example the vehicle is late with respect to the time table).

5.2 Actors

iTLC, RO, PBC, OBU, PRG, EB

5.3 Pre-Conditions

The intersection is controlled by an iTLC that supports the use case Public Transport Priority.
The PBC has been, according to the policy of the RO, configured to allow priority for public transport vehicles at the intersection.

5.4 Trigger

The PRG determines, based on current vehicle data from the OBU, that the public transport vehicle is in service and will pass the intersection within [5] minutes.

5.5 Normal Flow

The iTLC determines, based on role= publicTransport (1) and subrole= don t care, that priority for a public transport vehicle has been requested.
The iTLC uses the routeName field in the SRM to determine the line number.

5.6 Post-Conditions

5.7 Exceptions

5.7.1 Exception #21 (Unknown Connection)

The PRG is not able to determine which connection the vehicle will take across the intersection.Handling: Flow: PRG_end_priorityrequest

6 Use Case: Priority for Trucks

6.1 Goal

The use case Priority for Trucks lets trucks pass an intersection with a minimum use of energy as possible ( green), at moments this is possible within the control policy. This is realised by minimising the number of stops, leading to less accelerations and decelerations.

6.2 Actors

iTLC, RO, PBC, OBU, PRG, EB

6.3 Pre-Conditions

The intersection is controlled by an iTLC that supports the use case Priority for Trucks.
The OBU of the truck provides the required data (among others the route the truck will take across the intersection).
The PBC has been, according to the policy of the RO, configured to allow priority for trucks at the intersection.

6.4 Trigger

The PRG determines, based on current vehicle data from the OBU, that the truck is in service and will pass the intersection within [5] minutes.

6.5 Normal Flow

The iTLC determines, based on role= commercial (9), that priority for a truck has been requested.
Based on the subRole it is determined which use case for commercial traffic must be selected:
subRole=requestSubRoleUnKnown (0)
subRole=requestSubRole11 (11), -- platoon
subRole=requestSubRole12 (12), -- EcoDriving
The iTLC determines, based on role= dangerousGoods (3) and subRole=don t care, that priority for a truck with dangerous goods is being requested.
The iTLC determines, based on role=specialTransport (2) and subRole=don t care, that priority for special transport is being requested.

Note: For EcoDriving the iTLC will provide priority if the vehicle can pass the intersection without stopping.

6.6 Post-Conditions

6.7 Exceptions

6.7.1 Exception #21 (Unknown Connection)

The PRG is not able to determine whichconnectionthe vehicle will take across the intersection.Handling:

Flow: PRG_end_priorityrequest

7Appendix A: SSM status diagram

7.1 Normal flow

[ link ]

Figure 2 SSM status diagram normal flow

7.2 Exceptions

[ link ]

Figure 3 SSM status diagram - exceptions

#1 (Rejected by iTLC invalid priority request)	#9 (Vehicle characteristics)
#2 (Reject reservice locked- by iTLC)	#10 (Invalid ETA)
#3 (Reject by iTLC)	#11 (Vehicle characteristics have changed)
#4 (SRM Update timeout)	#12 (Change in Connection and/or approach at the same intersection)
#5 (ETA increase)	#13 (Changed route, not involving the intersection anymore)
#6 (Reject by iTLC during priority handling)	#14 (No cancellation received by the iTLC)
#7 (Processing timeout by iTLC)	#15 (SSM not received on time)
#8 (Granted timeout)

8 Appendix B: SSM status sequences

For diagnostic purposes the order of the SSM status values can be used to draw conclusions on the handling of the priority request. This is explained in the table below.

Status	Explanation
[requested] [processing] granted	This is the normal flow. The ITS application has used the priority request in its control and possibly the vehicle has passed the intersection more quickly.
[requested] processing	The normal flow, without granted. The ITS application has used the priority request in its control and possibly the vehicle has passed the intersection more quickly.
[requested] rejected.	The priority request has been rejected. This could have been caused by for example: The ITS application does not support the requested priority service. The priority service in the ITS application has been (temporarily) disabled. The intersection is not being controlled by an ITS application (for example it is amber flashing or turned off).
[requested] processing rejected	The priority request was accepted, however it cannot be serviced at this moment (any more). This could have been caused by for example: An incoming priority request with a higher priority An eco-driving truck cannot pass the intersection without stopping, therefore the priority service is cancelled. Exception #4 (SRM Update timeout)
[requested] reserviceLocked	The priority request has been accepted, however the priority service is not available because it would have too much of a negative impact on the traffic flow at the intersection.
[requested] processing reserviceLocked.	The priority request was accepted, however it cannot be serviced at this moment any more. This sequence will normally only happen when a priority request was made from a large distance; initially the request was accepted, but later on the ITS application concludes that the priority service is not available because it would have too much of a negative impact on the traffic flow at the intersection
[requested] processing maxPresence	Exception #14
[requested] [processing] granted maxPresence	Exception #11
[requested] [processing] granted rejected	Exception #4 (SRM Update timeout)

Tabel 2 SSM status sequenties

9 Appendix C: Background information

https://www.ifv.nl/kennisplein/Documents/20181119-IFV-Het-gebruik-van-optische-en-geluidssignalen-in-de-nacht.pdf

Emergency vehicle drivers are authorized to drive with optical and audible signals (OAS) during emergency drives (Priority 1 and A1 incidents). When drivers use these signals, they are a priority vehicle and may use certain exemptions from the Road Traffic and Traffic Signs Regulations 1990 (RVV 1990).

Drivers working with the ambulance may in some cases also use OAS for A2 trips. This research focuses only on A1 rides.
The police may also use exemptions from the RVV 1990 without optical and audible signals.

https://www.ifv.nl/kennisplein/Documents/20171019-IFV-Overzicht-van-verkeersbevoegdheden-bij-gebruik-van-vrijstellingen.pdf

Ignoring a red traffic light occurs at a speed of up to 20 kilometres per hour. At bridges and level crossings, the red light is not ignored and driving is prohibited (article 3 ROGs and industry directive).

Approaching and crossing intersections is done at an adjusted speed. When entering the intersection, the driver of the priority vehicle should assume that other road users have not noticed him and may therefore not let him go ahead. Therefore the driver must stop if necessary (Industry directive).

The driver crosses the intersection as close to the centre of the intersection as possible. Preferably, existing free traffic space is used instead of creating free space. Preferably, the following is chosen, in order of preference:

the normal driving lane for the chosen direction,
the driving lane in the opposite direction (Guideline for special traffic rights).

Interesse?

15 Priority services